Board Thread:Watercooler/@comment-3032314-20181119015150/@comment-26402117-20181128112338

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  and , 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  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  function :p

...

With those restrictions in mind, I don't think it's possible to replace T's  tag with a   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  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 if there's no   or