Topic on Extension talk:Linter

Issue

Paste the following in a wiki page:

<code>A piece of computer code
asdasdasd
<h2> buuu</h2>
zsadsdasd

Expected:

Output html should be similar to above.

Actual:

<p><code>A piece of computer code
asdasdasd
</code></p><code><h2><span class="mw-headline" id="buuu">buuu</span></h2></code><code><p>zsadsdasd
</p></code>

See it in action on this page (https://www.mediawiki.org/w/index.php?title=Project:Sandbox&oldid=2583108)

Possible solutions:

• Increase priority of this lint error - This seems to be creating huge rendering differences, and seems bad enough to either increase the priority of the "misnested" tag
• Set it as a separate high priority category
• Or decide whether this is actually a bug in the parser - and fix that

Notes: I've been seeing this for quite some time in some help pages (e.g. https://www.mediawiki.org/w/index.php?title=Help_talk:Searching&oldid=2475830 scroll down), and couldn't understand where it came from until I tried it in a different wiki, and it became obvious.

Note that high priority rendering categories are about whether rendering will change when Tidy is replaced with a RemexHTML based tool. It is not about whether the HTML output for a piece of wikitext matches expectations.

In this case, the actual HTML structure is slight different for Tidy, RemexHTML and Parsoid. However, the rendering in the browser is identical.

So, this doesn't belong in the high priority category. Right now, we don't want to confuse editors and add more work to their plate beyond what is required to switch from Tidy to RemexHTML. Once Tidy is replaced, we could change the priority of linter categories based on new desired goals.

Err, rendering did change. Did you actually look at the url?

Try looking at https://www.mediawiki.org/w/index.php?title=Project:Sandbox&oldid=2583108&action=parsermigration-edit. Maybe you've customized the code tag in your browser or personal css, and you don't see the gray areas.

Anyway, it is up to you. Personally I found it so odd, that I began to think there was something wrong with my browser.

Ah, sorry, you are right. I looked at output in my browser outside the mediawiki CSS settings where the differences don't show up. This doesn't happen with the small tag (except for the vertical whitespace diff). Parsoid's analysis for linter errors treats all formatting tags identically, and both code and small are formatting tags. But, looks like CSS for the code tag changes how the heading and paragraph render.

We could add a special case for the code tag, but I am inclined to let this be for just now unless there are a lot of code-tag-related issues in practice.

Hmm, you're right. Those come from the wiki-specific CSS styles. Still, the way the way those code tags are nested results in invalid html, see :

https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.mediawiki.org%2Fw%2Findex.php%3Ftitle%3DProject%3ASandbox%26oldid%3D2583108

That might be a completely separate problem, maybe https://phabricator.wikimedia.org/T134469. I suppose that code tags aren't used that much in articles, and because the linter detects this it might be reasonable to let editors take their time fixing it.

Output compliance wrt content model constraints is covered in Parsing/Notes/HTML5 Compliance ... that is a separate discussion.