Template talk:Rule

Simplified code

On the lines of using only the hr tag without being nested in a div, I made some minor edits and shortened the template to this:

<hr style="background-color: #000; color: #000; {{#if:{{{width|{{{1|}}}}}}|width: {{{width|{{{1}}}}}}; |}}{{#switch:{{{align}}}|left=margin: 2px auto 2px 0|right=margin: 2px 0 2px auto|#default=margin: 2px auto}}; {{#if:{{{height|}}}|height: {{{height}}}; }}{{#if:{{{style|}}}|{{{style}}};|}}" />

You may notice I changed the margins. Using the div tags originally added some space due to the CSS defined in the site's stylesheet. This approximates it, though it can be changed, of course.

I tried to use it in every way defined by the original template and haven't found differences yet, other than that the div codes are now gone. Any feedback is welcome. The Haz _talk 18:40, 13 February 2014 (UTC)

Rule width when greater than 100%: add max-width?

This template doesn't work well when the specified width is greater than the parent width. This often happens with long rules and small screens (e.g. mobiles and e-readers).

I think adding "max-width:100%;" to the CSS will help here. This would "cap" the width at the parent container's width and stop the otherwise-fixed width rule from spilling over the right hand margin. Inductiveload—talk/contribs 07:13, 17 September 2018 (UTC)

 Comment In the majority of cases where a fixed rule width is specified, the intent of the editor is to limit the rule to some portion of the page-width less than 100%. Perhaps Inductiveload's proposal would be improved by (say) making max-width:80%? 114.74.168.126 07:33, 17 September 2018 (UTC)

A very good point. I suppose there are two kinds of rule:

• Where the length is derived from something else, like a title, when you may want 100% (because on a small screen the title would also go to 100%). These are common on title pages.
• Where the intention is "some but not all of the page", where around 80% would retain the feel. Common for section dividers.

The problem is that this template is used for both and there is no semantic markup to work out what was meant. Perhaps a max-width parameter would work? I don't know what the default should be. 100% would be most similar to the current behaviour. Either way, the difference would only be seen on very small screens/wide rules, and therefore only small (as 20% of small is small) so I don't have strong feelings either way. Inductiveload—talk/contribs 07:45, 17 September 2018 (UTC)

There is a small semantic hint, in that {{rule}} or {{rule|100%}} imply the new max-width: ought to be set to 100%; {{rule|x%}} where x>100% leads us back to the basic problem reported (editor being silly?)…

In fact any {{rule|p%}} where width is specified proportionally should scale correctly anyway. It is fixed em, px etc values which happen to exceed the value of 100% which are problematic — and only a javascript query or perhaps clever use of CSS3 calc() function can detect that…

Needs further thought and investigation! 114.74.168.126 08:58, 17 September 2018 (UTC)

I have gone ahead and added max-width:100%;. This is at least less wrong than allowing it to escape past the right-hand margin. Whether it's better to use 80% or 100% is a secondary concern. My feeling is it's better not to put hardcoded words into the editors' mouths and have them use a percentage width if that's what they actually meant. Alternatively, add a max-width parameter and use {{{max-width|100%}}} to allow exact control of the width in constrained containers. Inductiveload—talk/contribs 12:48, 29 May 2020 (UTC)

Lines disappeared

Lines have disappeared unless "h=1px(or more)" is added. I'm not sure if this is a general issue, but this has happened at least to me. --AragonChristopherR17Z (talk) 03:12, 10 September 2020 (UTC)

@AragonChristopherR17Z: Somehow the global CSS has changed to hr { height: 0; }. I'm not sure how, where or when, but as a response, this template now sets an explicit 1px default value. Thank you for the report! Inductiveload—talk/contribs 09:48, 10 September 2020 (UTC)

See also Wikisource:Scriptorium#Missing_horizontal_rules_(height:0_in_global_CSS) for wider discussion about this defect. Inductiveload—talk/contribs 11:42, 10 September 2020 (UTC)

using rule in table

@Inductiveload:: Hi, your changes of today broke my usage of "rule" in tables. I fixed the tables involved, but why can't I do it the way I did it before? See Page:EB1911 - Volume 28.djvu/843. The broken version is at [1]. Library Guy (talk) 16:52, 1 April 2021 (UTC)

@Library Guy: There was a newline that clearly doesn't play well in tables. It seems to work now.

However, this use of {{rule}} as a table divider is very strange and seems like misuse of the <hr> element. If you're using inline CSS anyway, why not just set border-bottom:1px solid black; on the top row (so it reads |-style="text-align: center; border-bottom:1px solid black;")? Inductiveload—talk/contribs 17:02, 1 April 2021 (UTC)

@Inductiveload:: I guess I'm the only one who uses it this way? It was a way that worked. Thanks for your alternative suggestions. I've used the CSS approach in the past, but just throwing in rule seemed easier to remember and deal with. My old version now works with your fix, thank you. And I'm sure many of my other table formatting efforts are working better now. I actually used to use hr in these situations, but rule comes out black whereas hr didn't. It was actually a big advance for me to start using the parallel bar syntax, "||". There are so many way to do things, and each of us thinks ours is the best I suppose. Library Guy (talk) 17:27, 1 April 2021 (UTC)

margin-tb

It seems that the margin-tb parameter stopped working. Could @CalendulaAsteraceae:, who has made some recent changes there, check it, please? -- Jan Kameníček (talk) 16:30, 7 August 2023 (UTC)

@Jan.Kamenicek: Oh yikes I totally forgot about that one somehow. I've added it back to the template and put it in the testcases page, along with the other parameters that weren't there. —CalendulaAsteraceae (talk • contribs) 02:43, 8 August 2023 (UTC)

Margin parameters

It would be very useful to be able to set top and bottom margin parameters separately, so I've added new parameters to Template:Rule/sandbox (they're working as expected at Template:Rule/testcases). Was going to name them |margin_t= and |margin_b=, but this seems to add a lot of extra text to the template call, so I ended up using |mt= and |mb=, and adding a new alias for |margin_tb= (|mtb=). Would anyone object if I added these changes to the main template? --Yodin^T 18:25, 20 December 2023 (UTC)

With no objections I've added the new params to the template. --Yodin^T 20:17, 30 December 2023 (UTC)

@Yodin: Sorry, I meant to look at it but it completely slipped my mind. My immediate thought when you posted the question was why not solve this using Index CSS? We're trying to get away from direct formatting parameters in these templates because it leads to a completely unbounded set that is impossible to maintain. Xover (talk) 20:53, 30 December 2023 (UTC)

@Xover That might work for novels, where the formatting is pretty uniform throughout the book, but often in periodicals, the amount of space above/below rules varies each time, sometimes from page to page, and is often a different amount above and below the rule. They'll often have dozens of different rule types throughout a volume, with different widths, heights, double and single, etc. etc., with different amounts of space above and below each time. Another case is where you have a double rule: setting |margin_tb= will add a gap between the two rules as well as a fixed space above and below them. And if the template allows you to set these non-standard space amounts, to override the amount of margin from the default (whether the standard Wikisource CSS, or Index CSS), using |margin_tb=, then allowing you to set top and bottom margins separately will make life much easier. Even if you were phasing |margin_tb= out completely, it would really help to allow separate margins amounts above and below until this happens. --Yodin^T 21:22, 30 December 2023 (UTC)

Some periodicals are like that, sure, as are some novels; but most of them are pretty uniform. In other words, these parameters are designed to solve one special case. And therein lies the problem: for the next special case it's left and right margins, or line style, or… All our templates have endless options to try to cater to the accumulation of every special case anyone has ever run into. Until they agglomerate enough such options that someone turns them all into a "style" parameter and now we're putting inline CSS into every template, at which point we might as well ask people to write raw HTML.

The use case you described can be equally well covered by adding a unique class and styling it to your heart's content in that work's Index Styles. The formatting you're trying to achieve is unique to that work, so the complexity of the styling for it should preferably be confined to that work. See Help:Page styles for some examples and class naming conventions (examples are for tables and toc right now, but I intend to add more examples as I run across other good cases). Xover (talk) 22:28, 30 December 2023 (UTC)

I've been meaning to look into using index css for a while now, but have been putting off understanding how Index/Page Styles work and best practices, etc. (it's much easier to just continue using templates); I really do need to just read through the docs you linked to. As a web dev I completely understand why it's a terrible idea to use loads of inline CSS, but on the other hand, do you think there's ever a case inline styles, for one-off cases, etc.? Or are you an Index Style purist? Either way, thanks for your patience talking this through rather than just reverting straight away! --Yodin^T 00:31, 4 January 2024 (UTC)

Oh, there's definitely going to be some use cases for pretty much any horrible practice. For example, some title pages are going to require advanced formatting that is ad hoc and specialised enough to not merit abstracting into Index Styles, much less be directly supported by a template, so we're going to have raw HTML and CSS in wikipage content there. But I think that as much as possible we want to contain the pain of these in the pages that need them rather than move it out to a template where everyone pays the prize; and if we provide such a facility in a template "for edge cases" people will start using it whenever it seems convenient. The judgement of when it is appropriate to use such facilities is actually a pretty technical skill, and is not a skill you can assume the general on-wiki contributor has.

For some templates we are going to be stuck with raw style parameters for a long long time, because every single use is unique and migrating to something else requires migrating individual pages one by one and manually. For others we can find common patterns and migrate uses to something better abstracted (for example, small/medium/large margins vs. passthrough raw CSS units). But we do want the general trend to be away from that practice, and certainly not to add new instances of it that we know we are going to have to migrate away from again later. Especially when the community is resistant to any change they do not immediately understand (cf. e.g. WS:S right now, where the expressed opposition somewhat boggles my mind).

And even ignoring technical debt I think it is likely that we will be left with some edge cases here and there, that are common enough (numerous enough) that having to add them to every Index Styles page manually is not reasonable, but where there is also enough justified variability that we cannot easily abstract it into template logic without basically providing a raw style parameter. That's where we're going to run into the really tough calls about where and how to solve the particular issue. These calls are also going to be a moving target, to some degree, because the facilities available are changing over time. For example TemplateStyles (which is the underlying facility Index Styles uses) does not currently support @import, CSS variables, LESS, or interpolating template parameters into the style sheet. It is likely that it will eventually pick up some kind of facility for that kind of functionality, and that is going to change the calculus for some of these cases.

In any case… All of that is to say that I am extremely sceptical of adding any new template parameters that provide direct styling of the |margin= and |style= kind. It's the same kind of problem we've grappled with in web dev since the beginning (semantic vs. physical markup was being discussed even in the context of WorldWideWeb/Nexus and Mosaic, and both the early "1.0" draft and the 1995 HTML 2 spec tried to address it, even if the solution proposed by Howcome in 1994 took another decade plus to be established as best practice). The context is a little different in a wiki, and for Wikisource (vs. Wikipedia), but the underlying issue is the same. Xover (talk) 08:44, 4 January 2024 (UTC)

Oh, PS (as if my reply wasn't long enough already)… I am not going to revert your addition of these parameters. There is no broad consensus in the community to justify a bright-line no to that approach, so I have no grounds beyond personally disagreeing with it for reverting (and I don't like reverting on that basis). Instead I am going to try to persuade you of the error of your ways and get you to revert it yourself. :) Xover (talk) 09:31, 4 January 2024 (UTC)

Yep, that makes sense. 👍 Might take a while to get fully used to the Index styles approach, but I don't want to add to the backlog in the meantime, so I'll revert the changes now! --Yodin^T 01:28, 8 January 2024 (UTC)