Page MenuHomePhabricator

Overlapping with <noinclude> causes breakage (like <noinclude><poem></noinclude></poem>)
Open, LowPublic

Description

Author: djr013

Description:
Overlapping (not nesting) <poem> tags with <noinclude> results in one or both of the two breaking. By overlapping, I mean situations such as <noinclude><poem></noinclude></poem>. While looking at this, it might appear to be an instance of invalid HTML, it ain't HTML. Apologies if I am mistaken and such overlaps are strictly disallowed in these tags.

The expected result would be that <noinclude> and its closing tag would take precedence over any formatting tags, in the above example stripping the transcluded text of the first <poem> and leaving the closing tag for later interpretation within the page it is transcluded into.

See URL for demonstration of issue. This causes problems most prominently on Wikisource which has heavy content transclusion use and where multi-page poems are fairly common.


Version: unspecified
Severity: minor
URL: https://test.wikipedia.org/wiki/Multipage_poem_test

Details

Reference
bz55825

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:12 AM
bzimport set Reference to bz55825.
bzimport added a subscriber: Unknown Object (MLST).

Is there a minimal testcase (e.g. wikipage) to reproduce the problem?

djr013 wrote:

(In reply to comment #1)

Is there a minimal testcase (e.g. wikipage) to reproduce the problem?

Yes, I put one in the URL field of the bug: https://test.wikipedia.org/wiki/Multipage_poem_test

Thanks,

noinclude (and includeonly and onlyinclude) a prefered over any other tag, because there are special for the parser.

You can use <poem><nowiki></noinclude></nowiki></poem> when you want noinclude show as poem.

The solution is to simply close the poem tag before the noinclude, then reopen it another time. If the poem tag formatting is neutral, then it works well enough. Both tags are hacks. <shrug>

djr013 wrote:

(In reply to comment #3)

noinclude (and includeonly and onlyinclude) a prefered over any other tag,
because there are special for the parser.

You can use <poem><nowiki></noinclude></nowiki></poem> when you want
noinclude
show as poem.

Right, the problem is that <poem> is causing <noinclude> to show when it isn't meant to, among other related issues.

(In reply to comment #4)

The solution is to simply close the poem tag before the noinclude, then
reopen
it another time. If the poem tag formatting is neutral, then it works well
enough. Both tags are hacks. <shrug>

That's a way to avoid the conflict, yes. The problem, if this is to be considered problematic, is that it's semantically incorrect. You end up with multiple sequential poems, marked in HTML as multiple independently identified and formatted divs and paragraphs, rather than one continuous poem/HTML div/paragraph.

But beyond that, unless I am mistaken, it might perhaps be considered a bug that <poem> can break <noinclude> to begin with.

Thanks,

No different from if you were incorrectly using <ref>, <pre>, <nowiki> and other hacks of html, where if you don't close tags before opening others it breaks. Remember that they are not true html tags. Try and put some expanding templates inside some tags and they fail miserably, which is why we have magic words like {{#tag:...}} to make things function properly, the issue is as stated above, we are not properly nesting open and closing of tags.

Poem is just a formatting, nothing more, it neither shows starts nor ends of poems. You can correctly format poems by closing the poem tag inside <noinclude>. Alterntiavely, if you want correctly formatted then you can format without using poem and just use <br />

The issue is also due to the ProofreadPage extension and how we stick pages together, and have the header and footer components on the one page where it is just a javascript presentation, rather than three separate components. It is all less than perfect. C'est la vie.

djr013 wrote:

(In reply to comment #6)

No different from if you were incorrectly using <ref>, <pre>, <nowiki> and
other hacks of html, where if you don't close tags before opening others it
breaks. Remember that they are not true html tags. Try and put some
expanding
templates inside some tags and they fail miserably, which is why we have
magic
words like {{#tag:...}} to make things function properly, the issue is as
stated above, we are not properly nesting open and closing of tags.

Poem is just a formatting, nothing more, it neither shows starts nor ends of
poems. You can correctly format poems by closing the poem tag inside
<noinclude>. Alterntiavely, if you want correctly formatted then you can
format
without using poem and just use <br />

The issue is also due to the ProofreadPage extension and how we stick pages
together, and have the header and footer components on the one page where it
is
just a javascript presentation, rather than three separate components. It is
all less than perfect. C'est la vie.

The testcase page I linked shows that this happens without ProofreadPage's javascript effects. What you can and can't do by avoiding using <poem> is a mixed bag. There's a few tests on the linked test page, feel free to mess around with these.

While I would like to emphasize the apparent issues of <poem> breaking <noinclude>, if it's as simple as "fix issue by not using tag at all," then please mark this bug as "won't fix." (Sorry if I come off as rude, just trying to be brief!)

Not my call on how to rate this, I am not a hacker. I am more saying that this is an artefact of a local tag (WMF) that is not standards compliant, and it is just one of many that have a similar behaviour.

TTO edited subscribers, added: ssastry, cscott, TTO; removed: wikibugs-l-list.

Is this realistically fixable, given the way extension tags are currently handled? Could it be solved when Parser.php is shown the door?

Seems that it would be better to flag this for a linter fix, rather than an ugly hack of wikimedia. We have to learn to do things properly, and it isn't as though it is problematic to close <poem> on one page and reopen on the next.

Seems that it would be better to flag this for a linter fix, rather than an ugly hack of wikimedia. We have to learn to do things properly, and it isn't as though it is problematic to close <poem> on one page and reopen on the next.

Yes, I agree.