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

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. 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 ''' tags. I did some investigation and made a demonstration of my results, but here's the short version:


 * tags ignore newlines, so multi-line text is only possible via  tags or block-level children
 * tags ignore inline CSS, so we can't use e.g.
 * Children of  tags also ignore inline CSS; we can get around this limitation by wrapping them in a   tag (i.e.   ), but other wrappers don't seem to work
 * tags render,  , and   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  tag with a   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  property.

What do you mean by "a CSS attribute"? As far as I know, the  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   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  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?