Page MenuHomePhabricator

List incorrectly terminated when multiline <div> or table embedded inside it
Closed, DuplicatePublic

Description

Input markup:

# Item 1 
#*<div>
</div>
# Item 3

Generated output:

<div class="mw-parser-output"><ol><li>Item 1
<ul><li><div></div></li></ul></li></ol>

<ol><li>Item 3</li></ol>
</div>

Expected out-put:

<div class="mw-parser-output">
<ol><li>Item 1
<ul><li><div></div></li></ul></li>
<li>Item 3</li></ol>
</div>

This premature closure of the outer list has generated a NUMBER of Lint-errors at English Wikitionary, such as here - https://en.wiktionary.org/w/index.php?title=%E1%BC%88%CF%81%CE%B9%CF%83%CF%84%CE%BF%CF%86%CE%AC%CE%BD%CE%B7%CF%82&action=edit&lintid=10907886 when using the rfquote template, which of itself does NOT contain errors.

Event Timeline

Aklapper renamed this task from List incorrectly terminated when mutliline DIV embdeeded inside it. to List incorrectly terminated when multiline <div> embedded inside it.Dec 21 2018, 7:01 PM
Aklapper added a project: MediaWiki-Parser.

I'd say the input markup above is incorrect, as its first two lines are indented.
The expected output also looks broken: It has two <ol> and only one </ol>.

Also see T7718 (if I get it right).

Updated original example to be clearer.

Aklapper triaged this task as Lowest priority.Dec 22 2018, 3:22 PM

Why exactly is the "expected output" listed above not like this?:

<div class="mw-parser-output">
<ol><li>Item 1</li>
<li><ul><li><div></div></li></ul></li>
<li>Item 3</li></ol>
</div>

Because the UL list should be part of the first item, Unless I am misunderstanding HTML

Because the UL list should be part of the first item, Unless I am misunderstanding HTML

Hmm, not in my understanding. In your input markup you define a second item as there is a second line starting with # so why should it be part of the first item?

I don't know what "BOX based DIV" means exactly, and how that is related to having an unordered list in an ordered list item, and which "first item" you mean (in the unordered or in the ordered list?), and I am not into templates, sorry.

This was what I was trying to do:-

  • {{rfap||US|lang=en|inline=yes}}

This generates :-

<div class="mw-parser-output"><ul><li><div class="noprint request-box" style="width: auto; margin: 0; padding: 0.5em; border-collapse: collapse;overflow: hidden;"></div></li></ul>
<table style="background:#FFFFFF; width:90%; margin: auto; border:1px dashed #999999; text-align:left">

<tbody><tr>
<td><a href="/wiki/File:Headset_icon.svg" class="image"><img alt="Headset icon.svg" src="//upload.wikimedia.org/wikipedia/commons/thumb/7/7b/Headset_icon.svg/20px-Headset_icon.svg.png" width="20" height="23" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/7/7b/Headset_icon.svg/30px-Headset_icon.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/7/7b/Headset_icon.svg/40px-Headset_icon.svg.png 2x" data-file-width="119" data-file-height="136" /></a>
</td>
<td>This special page needs <a href="/wiki/Category:Requests_for_audio_pronunciation_in_English_entries" title="Category:Requests for audio pronunciation in English entries">audio files</a>. If you have a microphone, please <a href="/wiki/Help:Audio_pronunciations" title="Help:Audio pronunciations">record some</a> and <a href="https://commons.wikimedia.org/wiki/Special:Upload" class="extiw" title="commons:Special:Upload">upload</a> them. <small>(For audio required quickly, visit <a href="/wiki/Wiktionary:APR" class="mw-redirect" title="Wiktionary:APR">WT:APR</a>.)</small>
</td></tr></tbody></table>
</div>

Which Linter doesn't like claiming that there is both a MISSING DIV in the respect of the opening and a "Stripped" DIV in respect of the closing.

If the parser was CORRECTLY embedding the DIV, then the pair of DIV tags would be matched, but the parser seems incapable of doing something that simple.

ShakespeareFan00 renamed this task from List incorrectly terminated when multiline <div> embedded inside it to List incorrectly terminated when multiline <div> or table embedded inside it.Dec 22 2018, 10:11 PM

For starters, the table in Template:request box should be converted to nested divs. For the actual issue here, the newlines in the source of that template are probably what's causing the behavior here, but the current markup will not work if they are removed; either the table would have to be converted to use HTML-style tags, or (as I already suggested, and definitely recommend) the table would have to be replaced with a div-based design.

Or you could actually FIX the parser to SEE that the entirity of the DIV should be within the list item?

If by "you" you mean "me, Dinoguy1000", then you need to keep in mind that not every commentator on Phabricator is a MediaWiki developer; personally, I have never directly contributed to the MediaWiki software, and don't understand any relevant programming languages well enough to do so competently. If you just meant in general, then there is definitely a ticket floating around already for list items to properly support multiline content, and the reason it hasn't been done yet is because it's a relatively minor feature request, developer time is limited, etc. etc.

In the meantime, ensuring that wiki content is not broken is the responsibility of local editors on that wiki; I have told you how you or someone else can fix this particular breakage. Just because it's not the answer you wanted, doesn't mean it isn't a valid answer.

This generates :-
[...]

I see no <ol> in there so I'm not sure how much it is related to the testcase in the task description...
(Plus IMHO (ab)using a <table> purely for layout instead of tabular data is really the more horrible and fix-worthy issue in this ticket currently.)

Or you could actually FIX the parser to SEE that the entirity of the DIV should be within the list item?

Well, T212509#4842163 showed that we have no shared interpretation how the parser should treat #*<div>\n</div>.
Hence it's unclear how a so-called "fix" should look like. (Once that has been agreed on you could actually fix the parser by contributing a software change.)

Okay so if it's an issue of bad formatting, Ticket closed.

@ShakespeareFan00 I have properly converted the template to use divs. While the appearance now is not pixel-for-pixel identical with the table-based template, I did attempt to match it as closely as reasonable; no one should notice the difference unless they are looking for it specifically. In the future, please be willing to ask for help before you decide that something can't be done.

The image should be to the left of the text, your version puts it above.. I might revert back to the "known" but broken table-based version until someone can actually make an identical version.

Changes moved to a sandbbox - And tested here - https://en.wiktionary.org/wiki/Template:rfap/sandbox

The table layout and the DIV based layout do not produce the same result.

Of course they're not going to produce the same output, if you add extra CSS. For starters, could you share your environment (device type, browser/browser version, and OS/OS version), as well as a screenshot of the current version of {{request box}} as it appears for you?

Let's have further discussion on the wiki - Anyway see - https://en.wiktionary.org/wiki/Template:rfap/sandbox

The top is the table based template, The bottom is the DIV based one, adding the image in certain instances caused the line text to jump. When I adjust the browser width, in the table based version the image remains at the left, in the DIV based one it moves above the text.

Windows 7, using Firefox 66.0a1

(The really up-to date way of doing this would be a (CSS) grid based layout in the DIV's but not many browsers support that yet, hence the (mis)use of a table for getting proper layouts.)