Board Thread:Watercooler/@comment-3032314-20181119015150/@comment-3032314-20181125053146

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, so the Lua side is already pretty simple. ;)

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

template

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):

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

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):

Speedit wrote:
 * I personally think HTML5 can allow semantic presentation for this situation :D
 * The,   and   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:


 * 
 * 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? ¯\_(ツ)_/¯


 * 
 * I chose to replace  tags with CSS (specifically,  ), since the line breaks seemed presentational to me. Should we bring them back?


 * 
 * This is currently used as the wrapper for T. I don't think we'll find a more appropriate tag.


 * 
 * Confusingly, this represents a term being defined, not the definition itself! Might be useful for parameter names?


 * 
 * This apparently represents vocalized stress, equivalent to italics in print. Probably not what we're looking for.


 * 
 * 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.


 * 
 * Most multiline instances of T are also wrapped in a (non-escaping)  tag. It might be a good idea to do that automatically in the module.


 * 
 * This is used pretty much everywhere. Carries no special meaning, and has no default styles; nice and simple.


 * 
 * Represents important, serious, or urgent text. Probably not what we want.


 * 
 * 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 . This sounds pretty useless to me, especially for our purposes.


 * 
 * 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  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  or   attributes as non-portable, but how would it affect infoboxes or  s?

Speedit wrote: Mercury recently began respecting inline styles inside Portable Infoboxes (though undocumented). Users on Dev Wiki [#Installation 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:

This has been possible since v0.6.0, but it's a lot clunkier right now because a) you need to use the selector, and b) you need to add   to override inline CSS. Neither is particularly ideal.

A future version of T might also include a  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:

code1

...you could write this:

code1

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:

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

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

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

IMO the inconvenience of ing 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 [ ] 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  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  for the wrapper, which few wikis style directly. Conversely, many wikis customize the default appearance of  tags, including our own. That  declaration is there to force the   wrapper to look like a , mimicking its original appearance.

More specifically, we use  because we don't know how individual wikis will restyle their   tags. Maybe they'll add a, maybe they'll change the   or  , or maybe they'll add  s or. I don't want to waste time playing whac-a-mole with resets, and I doubt anyone else does either. :p