Template talk:Rule

Add topic
Active discussions

Simplified codeEdit

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?Edit

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. Inductiveloadtalk/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%? 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. Inductiveloadtalk/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! 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. Inductiveloadtalk/contribs 12:48, 29 May 2020 (UTC)

Lines disappearedEdit

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! Inductiveloadtalk/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. Inductiveloadtalk/contribs 11:42, 10 September 2020 (UTC)

using rule in tableEdit

@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;")? Inductiveloadtalk/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)