FANDOM


  • Hello!

    As some of you may be aware, I've been working on Global Lua Modules/T over the past few days. One problem with the module as it's currently written is that it relies on a lot of inline CSS. Although there are only five calls to the mw.html:css, these add up quickly, especially when you use the module multiple times. In the interest of keeping T small and fast, I'd like to extract those styles into their own stylesheet:

    /**
     * 1. Removes backgrounds, borders, and other properties set on <code> elements.
     * 2. Restores the default font-family, which we removed in (1).
     */
    .t {
        all: unset; /* 1 */
        font-family: monospace; /* 2 */
    }
     
    .t--multiline .t__parameter {
        display: block;
    }
     
    .t__parameter-name {
        font-weight: bold;
    }
     
    /**
     * 1. Makes parameter descriptions look "lighter", regardless of the background
     *    they appear on.
     */
    .t__parameter-description {
        opacity: 0.5; /* 1 */
    }
     
    .t__parameter-description::before {
        content: "<";
    }
     
    .t__parameter-description::after {
        content: ">";
    }

    Based on some simple tests, I believe this change will make instances of T about 30% smaller than they are now. It also opens up some interesting possibilities, like allowing users to customize T by restyling the existing classes.

    There are, however, a couple of downsides to this proposal, which is why I'm bringing it up here instead of just making the change:

    1. Since T is now a global Lua module, we can't just dump the styles into MediaWiki:Wikia.css—they have to go in their own stylesheet.
    2. T is used throughout the wiki, so abrubtly yanking out the inline styles will cause breakage until/unless the new stylesheet is @imported.
    3. I'm not sure what the proper title is for this new stylesheet. Only two other modules depend on CSS (Global Lua Modules/NavboxBuilder and Global Lua Modules/Mbox), and both use MediaWiki:Global Lua Modules/$1.css, but I'm nut sure if that's correct.

    So, what do you guys think? Have I overlooked anything?

      Loading editor
    • Since T is now a global Lua module, we can't just dump the styles into MediaWiki:Wikia.css—they have to go in their own stylesheet.

      I'm on the fence with the idea of a separate stylesheet for T. The main reason for this is that Mercury recently began respecting inline styles inside Portable Infoboxes (though undocumented). Users on Dev Wiki see inline styling (btw opacity should be 0.75 :p).

      There's two sides to this really:

      1. Is it okay to make T Lua code more simple by adding new dependencies? Assuming CSS is kinda more cumbersome to install than JS and Lua here.

      • I personally think HTML5 can allow semantic presentation for this situation :D
      • The <code>, <b> and <i> tags are much better to use than default styling.

      1. Wouldn't styling and data attributes make it very cumbersome to customise on wikis? How could we ensure that T output isn't overqualified as it is currently? :/

      • I absolutely agree that inline styling should go. Classes would be nicer than data attributes. Not sure whether they trip the portability parser on inline elements tho.
      • However, the prefix and suffix for parameter descriptions could be configured from the T invocation, so that users won't need to install CSS in order to make T work :)

      T is used throughout the wiki, so abrubtly yanking out the inline styles will cause breakage until/unless the new stylesheet is @imported.

      In the past, staff copied code to Wikia.css, but I should confirm that with them. The T module is the best thing since sliced bread ;) but such a change will inconvenience other wikis.

      I'm not sure what the proper title is for this new stylesheet. Only two other modules depend on CSS (Global Lua Modules/NavboxBuilder and Global Lua Modules/Mbox), and both use MediaWiki:Global Lua Modules/$1.css, but I'm nut sure if that's correct.

      Sounds right (not sure if true in all cases). Should that be noted in DEV:CC for newcomers?
        Loading editor
    • An optimisation I can suggest for the current version: only adding all: unset to the wrapper when it's multiline. That gives the code wrapper its normal styling when inline. Hmm, seems like this causes ugly background reflow when it's inline.

      I asked Comtech about inline elements with classes in the portability parser, and it turns out they're likely to trip it. I still think that's a necessary cost for customisation, but data-* roles do lack this downside.

        Loading editor
    • Speedit wrote: Is it okay to make T Lua code more simple by adding new dependencies? Assuming CSS is kinda more cumbersome to install than JS and Lua here.

      Small correction: the main benefit of moving inline CSS to a stylesheet is that it would reduce the amount of HTML generated by each transclusion. Like I said earlier, there are only five calls to mw.html:css, so the Lua side is already pretty simple. ;)

      Let's talk about the HTML output, though! Consider the following transclusion:

      {{T|multiline=true|template
      |empty-value {{=}} ""
      |empty-description {{=}} 
      }}
      

      Right now, T transforms this humble blob of wikitext into the following HTML structure (note: this would normally be squashed onto a single line, but I've added comments for readability):

      <code data-t-role="wrapper" data-t-mode="transclusion" data-t-multiline="data-t-multiline" style="all:unset;font-family:monospace;"><!--
          --><span data-t-role="opener">&#123;&#123;[[Template:template|template]]</span><!--
          --><span data-t-role="parameter" data-t-index="1" style="display:block;"><!--
              -->&#124;<!--
              --><span data-t-role="parameter-name" style="font-weight:bold;">empty-value</span><!--
              --> = <!--
              --><span data-t-role="parameter-value"></span><!--
          --></span><!--
          --><span data-t-role="parameter" data-t-index="2" style="display:block;"><!--
              -->&#124;<!--
              --><span data-t-role="parameter-name" style="font-weight:bold;">empty-description</span><!--
              --> = <!--
              --><span data-t-role="parameter-description" style="opacity:0.5;">&#60;...&#62;</span><!--
          --></span><!--
          --><span data-t-role="closer">&#125;&#125;</span><!--
      --></code>

      Compare the results when inline styles are removed, and (most) data attributes are replaced with classes:

      <code class="t t--multiline" data-mode="transclusion"><!--
          --><span class="t__opener">&#123;&#123;[[Template:template|template]]</span><!--
          --><span class="t__parameter" data-index="1"><!--
              -->&#124;<!--
              --><span class="t__parameter-name">empty-value</span><!--
              --> = <!--
              --><span class="t__parameter-value"></span><!--
          --></span><!--
          --><span class="t__parameter" data-index="2"><!--
              -->&#124;<!--
              --><span class="t__parameter-name">empty-description</span><!--
              --> = <!--
              --><span class="t__parameter-description">...</span><!--
          --></span><!--
          --><span class="t__closer">&#125;&#125;</span><!--
      --></code>

      Still bulky, but it's definitely a step up! Here are the raw numbers for each version (for the sake of completeness, the original wikitext is 81 characters long):

      Size comparison (characters)
      Inline CSS Stylesheet
      Compressed 723 488
      Expanded 946 711

      Speedit wrote:

      • I personally think HTML5 can allow semantic presentation for this situation :D
      • The <code>, <b> and <i> tags are much better to use than default styling.

      I'm not sure I follow. Are you saying we should keep the inline CSS, since it's kinda-sorta semantic? Or do you mean that we should look for better HTML tags instead of using CSS at all?

      For the latter point, based on Help:HTML and the HTML Living Standard, there are 11 elements which might be correct:

      b
      I, uh... I'm still not sure what this is for. MDN calls it the "HTML Bring Attention To element", but both it and the spec say that its contents should carry no special importance. I'm not sure how notice this is supposed to be unimportant, though. I guess it could be useful? ¯\_(ツ)_/¯
      br
      I chose to replace <br> tags with CSS (specifically, display: block;), since the line breaks seemed presentational to me. Should we bring them back?
      code
      This is currently used as the wrapper for T. I don't think we'll find a more appropriate tag.
      dfn
      Confusingly, this represents a term being defined, not the definition itself! Might be useful for parameter names?
      em
      This apparently represents vocalized stress, equivalent to italics in print. Probably not what we're looking for.
      i
      Another frustratingly vague tag! This one apparently represents text that is somehow... different. The spec gives a few examples: taxonomic designations, technical terms, translated words or phrases, transliteration, character's thoughts, and ship names. Doesn't sound like what we want, but it's pretty ambiguous.
      pre
      Most multiline instances of T are also wrapped in a (non-escaping) <pre> tag. It might be a good idea to do that automatically in the module.
      span
      This is used pretty much everywhere. Carries no special meaning, and has no default styles; nice and simple.
      strong
      Represents important, serious, or urgent text. Probably not what we want.
      u
      It seems like the W3C and/or WHATWG members wanted to deprecate this tag, but for some reason decided that they couldn't. Both the spec and MDN say it represents text with a "non-textual annotation", but there are few examples of when you would need that. Conversely, there are plenty of examples of when you should use another tag, instead of <u>. This sounds pretty useless to me, especially for our purposes.
      var
      Represents variables, as you'd expect. Might be useful for parameter names?

      I didn't see any good tags for parameter descriptions or literal parameter values, but maybe I've missed something? What do you think?

      Speedit wrote: I absolutely agree that inline styling should go. Classes would be nicer than data attributes. Not sure whether they trip the portability parser on inline elements tho.

      Speedit wrote: I asked Comtech about inline elements with classes in the portability parser, and it turns out they're likely to trip it. I still think that's a necessary cost for customisation, but data-* roles do lack this downside.

      Gah, I completely forgot about portability! Thanks for bringing it up! :)

      I've heard something like this before: when I was helping the Final Fantasy Wiki transition their enemy stat infoboxes to a portable, multicolumn layout, I was told to use a data attribute instead of a class for the wrapper. I didn't see anything about the portability parser on the Portability Hub though; what are the consequences of tripping it? Like, I assume that's the thing that marks tables with colspan or rowspan attributes as non-portable, but how would it affect infoboxes or <span>s?

      Speedit wrote: Mercury recently began respecting inline styles inside Portable Infoboxes (though undocumented). Users on Dev Wiki see inline styling

      Hmmm, that makes things tricky. Would T still be useful to mobile users without inline CSS? If not, then this whole proposal is dead in the water. :(

      Speedit wrote: Wouldn't styling and data attributes make it very cumbersome to customise on wikis? How could we ensure that T output isn't overqualified as it is currently? :/

      Not sure what you mean by "overqualified" there, but wikis could add specialized CSS to override the basic styles I included above. For example, if a wiki wanted every instance of T to use Roboto Mono, they could add the following to their MediaWiki:Common.css:

      @import url("https://fonts.googleapis.com/css?family=Roboto+Mono");
       
      /* ... */
       
      .t {
          font-family: "Roboto Mono", monospace;
      }

      This has been possible since v0.6.0, but it's a lot clunkier right now because a) you need to use the selector [data-t-role="wrapper"], and b) you need to add !important to override inline CSS. Neither is particularly ideal.

      A future version of T might also include a class parameter, which would allow more fine-grained customization. For example, this would address the styling problem you mentioned a few days ago. Instead of this:

      <span class="code">{{t|l|code1|code2|...}}</span>
      

      ...you could write this:

      {{t|class=code|l|code1|code2|...}}
      

      Speedit wrote: the prefix and suffix for parameter descriptions could be configured from the T invocation, so that users won't need to install CSS in order to make T work :)

      My problem with this is that the prefix and suffix are purely presentational, so they belong in a stylesheet. Configuration would still be possible, though! Users could change every prefix and suffix with the following CSS:

      .t__parameter-description::before {
          content: "~{!";
      }
       
      .t__parameter-description::after {
          content: "!}~";
      }

      Alternately, they could use a wrapper (or maybe {{{class}}} in the future) and CSS like the following for a more limited change:

      .my-custom-class .t__parameter-description::before {
          content: "~{!";
      }
       
      .my-custom-class .t__parameter-description::after {
          content: "!}~";
      }

      A future version of T might also use custom properties, simplifying the CSS to:

      .t {
          --prefix: "~{!";
          --suffix: "!}~";
      }

      Speedit wrote: The T module is the best thing since sliced bread ;) but such a change will inconvenience other wikis.

      IMO the inconvenience of @importing a stylesheet is offset by the performance gains and number of future possibilities it unlocks. I might be a little biased, though. :p

      Speedit wrote: Should [MediaWiki:Global Lua Modules/$1.css] be noted in DEV:CC for newcomers?

      It would be nice to have official guidance on the matter, but OTOH maybe we want to discourage stylesheets for modules? Like you said, it is pretty inconvenient...

      Speedit wrote: An optimisation I can suggest for the current version: only adding all: unset to the wrapper when it's multiline. That gives the code wrapper its normal styling when inline. Hmm, seems like this causes ugly background reflow when it's inline.

      Hmm, maybe I didn't explain this very well? T originally used a <span> for the wrapper, which few wikis style directly. Conversely, many wikis customize the default appearance of <code> tags, including our own. That all: unset; declaration is there to force the <code> wrapper to look like a <span>, mimicking its original appearance.

      More specifically, we use all because we don't know how individual wikis will restyle their <code> tags. Maybe they'll add a background-color, maybe they'll change the font-size or line-height, or maybe they'll add margins or padding. I don't want to waste time playing whac-a-mole with resets, and I doubt anyone else does either. :p

        Loading editor
    • If the portability parser is tripedd in many pages or templates, our metrics for portability (as Vanguard) become visibly bad, which isn't a drastic issue so long as infoboxes are portable. But if it can be avoided, I recommend it. [data-t-multiline] isn't so bad as a selector, when I think about it.

      The metric essentially means "what proportion of this wiki's ns:0 pages consist solely of HTML output that Mercury can parse well?" It is used to flag issues and give attention to wikis whose article markup might be very very bad or entirely prohibitive.

      However, the T module isn't so useful in the mainspace away from Dev Wiki :)

      I'm not sure I follow. Are you saying we should keep the inline CSS, since it's kinda-sorta semantic? Or do you mean that we should look for better HTML tags instead of using CSS at all?

      Absolutely, better HTML tags. Here's what I think you could use:

      • Wrapper is usually <code> to signify it's a computer code fragment and is "short".
      • When multiline, the wrapper can be assumed to be 1. "long" and 2. a block-level element. Ideally, that should be rendered as a <pre> out of the box. This eliminates the need for presentational <br /> tags.
      • I agree that the <> around parameters are purely presentational tbh. Those could be handled by a CSS attribute, so that users don't have to understand the CSS content property.
      • The template name and curly braces are key. They're critical information of the T invocation that are required to transclude the template. So <strong> is fine.
      • The actual parameter list is an key-value list of associated items (in this case, parameter definitions). I would like <dl>, but it seems that dl is a block element. So the <span> parameter wrappers are okay.
      • Within the parameter wrapper, I would use <b> and <i> to emphasise the varying stress and context of the parameter key & description. That also maintains the styling within FANDOM.

        It seems like <dfn> would be a better description choice, but it isn't styled on FANDOM as one would expect.

      Here is what that looks like.

        Loading editor
    • Speedit wrote: If the portability parser is tripedd in many pages or templates, our metrics for portability (as Vanguard) become visibly bad, which isn't a drastic issue so long as infoboxes are portable. But if it can be avoided, I recommend it. [data-t-multiline] isn't so bad as a selector, when I think about it.

      The metric essentially means "what proportion of this wiki's ns:0 pages consist solely of HTML output that Mercury can parse well?" It is used to flag issues and give attention to wikis whose article markup might be very very bad or entirely prohibitive.

      Interesting, thanks!

      Still, it's weird that FANDOM would tell people to not use inline CSS, and then secretely penalize them when they switch to classes. I guess this is their "subtle" way of discouraging everything besides plain text and infoboxes?

      Speedit wrote:

      • Wrapper is usually <code> to signify it's a computer code fragment and is "short".
      • When multiline, the wrapper can be assumed to be 1. "long" and 2. a block-level element. Ideally, that should be rendered as a <pre> out of the box. This eliminates the need for presentational <br /> tags.

      While playing around with your other suggestions, I noticed that Mercury was behaving strangely when rendering <pre> tags. I did some investigation and made a demonstration of my results, but here's the short version:

      • <pre> tags ignore newlines, so multi-line text is only possible via <br> tags or block-level children
      • <pre> tags ignore inline CSS, so we can't use e.g. white-space: pre;
      • Children of <pre> tags also ignore inline CSS; we can get around this limitation by wrapping them in a <code> tag (i.e. <pre><code>...</code></pre>), but other wrappers don't seem to work
      • <pre> tags render <b>, <strong>, and <span> children in exactly the same way, so inline CSS is the only way to get bold text

      With those restrictions in mind, I don't think it's possible to replace T's <code> tag with a <pre> tag, even in multiline mode.

      Speedit wrote:

      • I agree that the <> around parameters are purely presentational tbh. Those could be handled by a CSS attribute, so that users don't have to understand the CSS content property.

      What do you mean by "a CSS attribute"? As far as I know, the content property is the only way to add presentational text.

      (It also doesn't seem very confusing to me, but maybe that's just my curse of knowledge kicking in?)

      Speedit wrote:

      • The template name and curly braces are key. They're critical information of the T invocation that are required to transclude the template. So <strong> is fine.

      I disagree. The braces are no more important than the pipes between parameters or the equals signs between parameter names and values. They're a required part of the syntax, yes, but I wouldn't call any of them "critical". You might have a point about the name of the template, but a) T is used for more than just templates, and b) that would require additional markup.

      Besides, more bold text would be distracting IMO.

      Speedit wrote: Here is what that looks like.

      You didn't mention this, but it looks like you removed opacity: 0.65; from that example? IMO italic text and the angle brackets don't do enough to distinguish parameter descriptions from literal values and names, so I'd rather keep that effect.


      So in summary, it sounds like we need to keep the inline CSS after all, in order for T to work on Mercury?

        Loading editor
    • Still, it's weird that FANDOM would tell people to not use inline CSS, and then secretely penalize them when they switch to classes. I guess this is their "subtle" way of discouraging everything besides plain text and infoboxes?

      Slight omission - classes that FANDOM makes available for user-generated content, such as .mw-collapsible and .wikitable, are considered portable. They're trying to discourage the creation of custom JS-powered elements.

      What do you mean by "a CSS attribute"? As far as I know, the content property is the only way to add presentational text.

      (It also doesn't seem very confusing to me, but maybe that's just my curse of knowledge kicking in?)

      By CSS attribute, I meant attr function :p That way, the description delimiters are in the DOM too.

      ...

      With those restrictions in mind, I don't think it's possible to replace T's <code> tag with a <pre> tag, even in multiline mode.

      Very disappointed to hear of the pre issue again :( but I've been pushing to have it fixed for a while. Could you S:C/bug about it?

      You can see the current method I use to bypass it at Installation, within syntaxhighlight tags.

      You didn't mention this, but it looks like you removed opacity: 0.65; from that example? IMO italic text and the angle brackets don't do enough to distinguish parameter descriptions from literal values and names, so I'd rather keep that effect.


      So in summary, it sounds like we need to keep the inline CSS after all, in order for T to work on Mercury?

      Yup. Unfortunately, I also can't find a correct HTML tag for de-emphasis of text. I also agree with adding a CSS stylesheet now. From the sounds of it, it would improve customisation and the code.

      To deal with subpar rendering on wikis without a stylesheet, I suggest something like this:

      1. Wikia.css & Common.css scanning in T, when called on a page prefixed with Template:T/doc
      2. throw an error in that page only if there's no Global Lua Modules/T.css or .t {

      Perhaps this should be a user error, so that it can have a link to CSS installation guidance.

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message