In T152821#4609102, @Dinoguy1000 wrote:

In addition, there isn't a 1:1 feature parity between wikitext and the underlying HTML tag it implements; list markup is probably the most obvious example of this - there is no way to specify HTML attributes or CSS in list wikimarkup (other than using wrapper elements like <span>, which still doesn't let you do stuff like set a custom start number for ordered lists).

In T152821#4609051, @StanProg wrote:

In T152821#3934035, @Izno wrote:

More generally, we should probably lint for any tag which is not on the whitelist. <img> is another.

MediaWiki can have custom tags, like <gallery>, including ones introduced by extensions (<mapframe>, <maplinks>), etc. This category should be based on a list of specific tags, that can be represented by wikitext (like <table>). This category will be very useful.

Yeah, this is a problem with CSS that I've observed also. We should probably remove the outline on focus for a few of those header elements.

In T152806#3741700, @DLynch wrote:

Any reason not to decline this?

I'm of two minds. The biggest argument for it would be consistency with current output -- wikitext + Tidy removes empty <tr>s, and people write pages expecting that. But unless this gets written into wikitext + RemexHTML, Parsoid would become out of sync with that behavior whenever the switch happens.

en.wp has proposed to have a bot sync from an admin-protected page. Obviously, we need to make sure there is consensus, but once we establish that, I suspect that we may be able to run it on other wikis.

Not tracking enough to keep around.

This has been fixed? If I view any of the links provided, the bibtex appears entirely within the pre.

ok ~

I would prefer to stop populating the category rather than a redirect as this will be confusing to editors ("a Category page that redirects to a Special page?").

This is fixed by Remex if not some version of Tidy between now and 2008.

Remex fixes this issue and as it will be the only way to get output in the near future, resolving this.

I can produce this on Firefox 62.0 64-bit on Windows 10.

In T205149#4607202, @Daylen wrote:

@Izno I'm using Vivaldi (which is built on Chromium). I've also tried it on Microsoft Edge and get the same issue. It doesn't seem to be a browser-specific problem.

This happens to me on Android Firefox Quantum. Is that what you're using here?

In T205025#4604310, @Addshore wrote:

Related:

• T194175: Make WDQS UI completely configurable for other Wikibase installations

There's some discussion about 'real name' at T154177: Change "Real name" to "Display name" that it might be worth a separate task entirely about "how should we deal with this field and/or is it exposed anywhere?". The OOUI problem should probably be fixed regardless.

I filed T204780: OOUI has a border in Timeless Special:Preferences but didn't want to make it a blocker (since a) it's Timeless and b) it's minor).

In T202921#4537253, @Schnark wrote:

In T202921#4535748, @Whatamidoing-WMF wrote:

One problem: If you choose the VisualEditor's wikitext mode as your wikitext editor, then I'm not sure what would happen if you https://en.wikipedia.org/wiki/Special:Random?action=submit (which VisualEditor ignores). The site's non-VisualEditor default, perhaps?

action=submit will always load the classical wikitext editor, regardless of namespace, wiki or any VE settings, with whatever toolbar (none/small/enhanced) you have enabled in your settings. And at least I use this to force the old editor, even though my default wikitext editor is the wikitext mode of VE.