Page MenuHomePhabricator

Tidy shouldn't reopen inline tags after the end of a block
Closed, DeclinedPublic

Description

There was a missing </small> in a users's signature in the [[Template
talk:High-traffic]] page. The software (I'm guessing it's HTML tidy) correctly
closed the missing tag, but then incorrectly reopened it on every block for
several sections (starting at the "Comments" section). It only ended (in the
"Category" section) after finding a matching <small>...</small> pair. It should
not reopen a tag on the next block after closing it on a block's closing tag.


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/w/index.php?title=Template_talk:High-traffic&oldid=102680041

Details

Reference
bz9661

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:37 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz9661.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

This is deliberate. The idea is that

<small>
This is lots of text.

I expect it all to be small.
</small>

should work, so that HTML neophytes need not be troubled by block vs. inline
tags (which is very unintuitive: why *shouldn't* you be able to declare multiple
paragraphs emphasized all in one go?). It will occasionally have weird effects
like this, and more subtle ones when it comes to CSS or JavaScript (because the
nesting won't be as intended). Possibly we should disable it, if possible, but
keep in mind that this will undoubtedly break a large number of pages.

I don't think changing it would affect many pages; every time I've seen where
the intention was to change the size of text for more than one block element, it
was done via CSS (often in a template).

Even if it's the case, it would be better to explicitly do the closing/reopening
in the parser, instead of letting tidy do the work, since with tidy there's a
greater chance of it spilling (sometimes even into the interface).

Izno subscribed.

Remex is doing similar with the page ID in question (replicating the small tag over and over, but outside of block tags), though it no longer closes the tag after finding a /small.

ssastry subscribed.

The behaviour of unclosed tags is well-defined by the HTML5 spec and we don't want to change that in custom ways in MediaWiki. It inhibits our ability to maintain our software. The fix here is to use Linter to fix the bad markup in the first place. Eventually, we want to add linter output to page preview post edits and perhaps later on, even require errors to be fixed before saving.

For my edification, where in the spec does it say to replicate the unclosed tag? It's a bit giggleworthy if that's what is supposed to pop out. :)

For my edification, where in the spec does it say to replicate the unclosed tag? It's a bit giggleworthy if that's what is supposed to pop out. :)

This applies to formatting tags .. and the relevant section of the spec is the adoption agency algorithm of the tree builder .. https://html.spec.whatwg.org/multipage/parsing.html#adoption-agency-algorithm