Template talk:Sign

From GodWiki
Jump to: navigation, search

Broken parameter semantics

The semantics of this template have been broken, pretty much since its inception, where it accepts (most) parameter values. The intent of the brokenness was good, since it was an effort to make things easier for users of the template, but turns out to be a problem in practice because it unnecessarily restricts the valid parameter arguments and leads to unexpected behavior.

In all parameters except |width= and |height= that accept values with units, the template expects those parameters to be specified without units, and it adds them automatically.

(I suspect this was initially the intent for |width= as well, given the |width=50 in the documentation example. But fortunately, width is passed unmolested and can accept any valid CSS width. The example therefore has an implied width: 50px, instead of the likely-intended width: 50%.)

The issues are

  1. Unit-less width arguments
    Behavior 
    Where the template takes |imgwidth=, it expects a numeral only, and forcibly adds "px" to the end when formatting the [[Image|...]] link. It then does some math on the value passed in, and sets the width of the table cell containing the image to imgwidth+8.
    Why it's a problem
    • If you do pass in e.g. |imgwidth=64px it will break because the image ends up being embedded with [[Image|filename|64pxpx|...]]. And the {{#expr:...}} computation that produces the table cell width will actually cause a parser error, due to "px" being used in a math expression.
    • If you want to specify the image width in non-pixel units, say e.g. |imgwidth=8em, it will break because the image ends up being embedded with [[Image|filename|8empx|...]]. It will also trigger the same parser error in the {{#expr:..}}. There is no way to use non-pixel units for |imgwidth=.
  2. Modifications to color arguments
    Behavior 
    Anywhere the template takes a color value, e.g. |bgcolor=, |outerbordercolor=, |bordercolor=, it requires (as documented) that the argument be an HTML color string without a # sign leading it. The template then adds the # sign to the CSS color: argument for that element of the sign.
    Why it's a problem 
    This one is actually a much bigger problem, and affects many transclusions of the template in practice.
    • If you do pass in a color with leading #, i.e. |bordercolor=#rrggbb this breaks because the color value set in the output becomes ##rrggbb which is an invalid CSS color value. Therefore, it will be ignored, and the default border color used instead. This affects a {{Sign}} in the Ankh-Morpork City Watch guild article (the "Watchman's Oath"), among others.
    • If you pass in a CSS color name, e.g. |bgcolor=red, this breaks because the color set in the output becomes #red which is an invalid CSS color value. Therefore, it will be ignored, and the default background color used instead. This affects the example in the template's own documentation!
  3. Modifications to CSS distance values
    Behavior 
    The |interval= parameter, which sets the bottom margin of the template ("interval" because it affects the spacing between subsequent consecutive signs, specifically), takes a numeral in implied pixels. It then forcibly adds "px" to the margin-bottom: style in the output.
    Why it's a problem
    • It actually isn't, in practice, only because |interval= is not used in any current {{Sign}} transclusions on the Godwiki.
    • However, it again prevents using non-pixel measurements like |interval=2em to set the distances. Here again, the style becomes margin-bottom: 2empx, an invalid CSS value that will be ignored.
    This is a concern for mobile use, since px units are not mobile-friendly. Modern web design principles strongly recommend that pixel units be avoided in favor of scaled units such as em. |interval= should support any valid CSS distance, just like |width= does by not forcibly adding a % sign.

What we can do about it

These issues were the original impetus behind my starting {{Sign2}}, which was intended to fix "all" of the issues with {{Sign}}. However, that overambitious goal got away from me, and {{Sign2}} was never completed.

It's now my belief that it would be better to just fix {{Sign}} incrementally in the areas where it can be fixed, and where this breaks existing articles' use of {{Sign}}, update those articles accordingly. (By adding # signs in front of arguments like |bgcolor=eeeecc, for example.) Those articles can easily be found using the Godwiki's search function, since strings like "bgcolor" and "outerbordercolor" are unique to the parameters of the {{Sign}} template. So, that's now my plan.

The only wrinkle is that most of these articles turn out to be Guild articles. I'm therefore going to place an announcement on Talk:Main Page that I'll be mass-editing Guild articles, specifically and exclusively to fix {{Sign}} transclusion parameters once changes to the template break them. That announcement and explanation, accompanied by a request that people understand the reasons for this violation of normal rules, will hopefully satisfy any potential objectors. -- FeRDNYC (talk) 21:35, 18 November 2018 (UTC)

Other template issues, not directly related to the above

In addition, unless someone can convince me otherwise I am going to completely blow away the |cat=Category name support in {{Sign}}. It serves no purpose other than to make the auto-categorization performed by templates built around {{Sign}} more obtuse. And it's literally the difference between writing |cat = Some category name in the parameters, vs. writing [[Category:Some category name]] immediately after closing the transclusion. There is no appreciable convenience gained by using the less-clear {{Sign|cat=Name}} version.

There's something to be lost, though, because |cat= makes it more confusing to do things like wrap the categorization in <includeonly>...</includeonly> (which you always want to do), or conditionalize it on specific namespaces or against a |nocat= type switch (which is often helpful to build into auto-categorizing templates, so they can be used in documentation examples without accidentally categorizing the documentation page).

So my plan is also to edit all templates that use {{Sign|…|cat=something}} to just {{Sign|…}}[[Category:something]] instead, and remove all code related to {{{cat}}} from {{Sign}}. -- FeRDNYC (talk) 18:40, 19 November 2018 (UTC)

Tick.png Done Support for |cat= has been removed, and all templates based on {{Sign}} have been updated to do their categorization directly, instead. -- 23:49, 22 November 2018 (UTC)
Um... WTF is going on with my signature? OK, so, that happened. (It showed up missing in the preview, too, but I decided to save anyway. Now this time around it's fine. Weird.) -- FeRDNYC (talk) 23:50, 22 November 2018 (UTC)