Template talk:Sign

From GodWiki
Jump to navigation Jump to 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
    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=.
    • OK, well, the previous point wasn't technically accurate because [[Image...]] doesn't accept non-pixel widths, so [[Image:Filename.jpg|8em]] will cause an error even if this issue is fixed. But the template still shouldn't be tacking px on after units: If the caller wants to specify an image width, it should be |imgwidth=40px or whatever. The spacing around the image can be created by styling the table cell with inner padding. rather than doing {{#expr:}} math. -- FeRDNYC (talk) 21:54, 14 December 2018 (UTC)
  2. Modifications to color arguments
    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
    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)

You fixed the color parameters, and I see no reason why you/we shouldn't just go ahead and fix the |imgwidth= parameter. I mean... there's precisely one place where that parameter has been used, and it sets {{{imgwidth}}} to 60 instead of the default 64... Honestly, I'm not even sure it's needed. -- Djonni (talk) 17:55, 15 December 2018 (UTC)
Oh, I fully intend to. I've also just not bothered, because as you say it's only one place. Other things have been more pressing and also I'm super lazy. But feel free if you're so inclined, and then it's dealt with. Status updates to Talk:Main Page#Sign template updates requiring page edits please. -- FeRDNYC (talk) 18:21, 15 December 2018 (UTC)
Tick.png Done
As of today all of this is finally dealt with. -- FeRDNYC (talk) 11:59, 12 January 2019 (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)

Unequal image cell widths in stub and picture hatnotes

So, just noticed that something in these edits has changed the behaviour of the left-hand image cell widths in {{stub}} and {{picture}} on desktop (no issue on mobile).

(I've viewed using Chrome on ChromeOS and on Windows, that's all I have at hand.)


Stub sign.pngThis article is a stub
This article is a stub. To help Godwiki, please consider expanding it.
Picturecamera.pngPicture needed
This article needs one or more pictures to be added to it. To help Godwiki, please consider adding suitable pictures.

I'm sure it's because the smaller text in {{stub}} is causing the table cell widths to be balanced differently, but I'm afraid my knowledge of the subtle art of CSS is inadequate for a quick, easy fix on it myself. :) -- Djonni (talk) 13:42, 12 January 2019 (UTC)

I'm sure it's because the smaller text in {{stub}} is causing the table cell widths to be balanced differently
— User:Djonni

Yeah, that's it exactly... basically, I'm no longer forcing the left-column width to a specific pixel size, which means the table gets balanced automatically based on the size of the content. And I guess the question is: is that wrong? IOW, yes the layour has changed from what it was previously, but... is that a bad thing?
I guess so, since the tables will so often be seen together and the imbalance looks weird. Easy enough to fix, I'll just stick a width="1%" into the cell definition for the left-hand column. -- FeRDNYC (talk) 08:12, 13 January 2019 (UTC)