Last modified: 2013-12-17 10:26:34 UTC
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.
Is there a minimal testcase (e.g. wikipage) to reproduce the problem?
(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>
(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.
(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.
