Page MenuHomePhabricator

Annoyance: Parser mis-"tidies" end of embedded <span> inside a <div> unless it has additional EOL context, Linter reports as a "Missing end tag","Stripped tag" error pair.
Closed, DuplicatePublic

Description

What's the problem:..
https://en.wikisource.org/w/index.php?title=Page:Life_of_Edmond_Malone.djvu/132

The relevant passage:

{{margin left|5em|{{smaller|
“Take pains the genuine meaning to explore;<br/>
There sweat, there strain; tug the laborious oar;<br/>
Search every comment that your care can find:<br/>
Some here, some there, may hit the poet's mind.<br/>
When things appear unnatural and hard,<br/>
Consult your author with himself compared.”}}}}

Template Expansion:

<div style="margin-left:5em;">
<span style="font-size: 83%;">
“Take pains the genuine meaning to explore;<br/>
There sweat, there strain; tug the laborious oar;<br/>
Search every comment that your care can find:<br/>
Some here, some there, may hit the poet's mind.<br/>
When things appear unnatural and hard,<br/>
Consult your author with himself compared.”</span></div>

Which is well formed.

Expected output:

<div style="margin-left:5em;">
<span style="font-size: 83%;">
“Take pains the genuine meaning to explore;<br/>
There sweat, there strain; tug the laborious oar;<br/>
Search every comment that your care can find:<br/>
Some here, some there, may hit the poet's mind.<br/>
When things appear unnatural and hard,<br/>
Consult your author with himself compared.”</span></div>

Actual Output:

<div style="margin-left:5em;">
<p><span style="font-size: 83%;">
“Take pains the genuine meaning to explore;<br />
There sweat, there strain; tug the laborious oar;<br />
Search every comment that your care can find:<br />
Some here, some there, may hit the poet's mind.<br />
When things appear unnatural and hard,<br />
</span></p>
Consult your author with himself compared.”</div>

The Span is being terminated a line earlier than it should be, despite the last line being part of span.

Adding a line-feed/carrige return between the end brackets solved the issue. (which seems to create an implied paragraph end.)

It is unreasonable for contributors to be expected to keep this in mind (not to mention confusing) for every single whitespace interaction that might happen, especially when templates are likely to be nested as in this instance.

The template expansion as noted was good, and even in the RAW version , ALL the tags are matched, so in addition the Linter message was confusing.

By comparison:

{{margin left|5em|{{smaller|
“Take pains the genuine meaning to explore;<br/>
There sweat, there strain; tug the laborious oar;<br/>
Search every comment that your care can find:<br/>
Some here, some there, may hit the poet's mind.<br/>
When things appear unnatural and hard,<br/>
Consult your author with himself compared.”}}
 }}

Generates as RAW:

<div class="mw-parser-output"><div style="margin-left:5em;">
<p><span style="font-size: 83%;">
“Take pains the genuine meaning to explore;<br />
There sweat, there strain; tug the laborious oar;<br />
Search every comment that your care can find:<br />
Some here, some there, may hit the poet's mind.<br />
When things appear unnatural and hard,<br />
Consult your author with himself compared.”</span>
</p>
</div></div>

which was clearly what was intended in the first place.

It is confusing and complicated to have this need to insert an otherwise completely unnecessary line-feed/carriage return,when the Parser should be intelligent enough to know it's still inside the SPAN when reading the expansion from the template, and processing it into HTML. Whilst in a simple example like this it was fairly easy to track down the cause of the error, in a more intricate template it would not be as straightforward.

Linter caught this glitch as a pair consisting of a 'Missing end Tag' and 'Stripped Tag' for the SPAN based portion, this despite the SPAN in BOTH examples having both an opening and a closing tag.

It would be nice to have ONE consistent rule ( and comprehensive documentation with examples) for when the additional LF/CR to mark the change of context needs to be added, or the parser patched so the additional LF/CR becomes unnecessary. This would make it far easier to diagnose REAL faults with templates, as opposed to ones generated unnecessarily from the parser itself.

Event Timeline

Restricted Application added subscribers: Liuxinyu970226, Aklapper. · View Herald TranscriptJul 13 2019, 4:55 PM

Other issues that may be related T185312 , T185827, T185563

@ShakespeareFan00: It is up to teams which tasks they want on their board, hence removing Parsing-Team--ARCHIVED.

Dinoguy1000 renamed this task from Parser mis-"tidies" end of embedded SPAN inside A DIV unless it has additional EOL context, Linter reports as a "Missing end tag","Stripped tag" error pair. to Parser mis-"tidies" end of embedded <span> inside a <div> unless it has additional EOL context, Linter reports as a "Missing end tag","Stripped tag" error pair..Jul 13 2019, 10:52 PM
ShakespeareFan00 renamed this task from Parser mis-"tidies" end of embedded <span> inside a <div> unless it has additional EOL context, Linter reports as a "Missing end tag","Stripped tag" error pair. to Annoyance: Parser mis-"tidies" end of embedded <span> inside a <div> unless it has additional EOL context, Linter reports as a "Missing end tag","Stripped tag" error pair..Jul 13 2019, 11:39 PM

Marking this as an 'Annoyance' type task in the heading, given that the issue noted can be carefully worked around, as indicated. It would be nice not to have to use the work-around in the future though, with a more robust parser being able to know it inside the <span> still and act accordingly.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptJul 14 2019, 12:44 AM