Bug 14634 – Webkit ignores </span> tag when </p> tag is missing

• Component: DOM
• Status: RESOLVED WONTFIX

[Matthias Fripp]

(If the URL above breaks, this link should always redirect to the appropriate page: http://dx.doi.org/10.1016/j.energy.2006.03.016 )

Webkit (current and previous versions) appears to require that each <p> tag be closed with a </p> tag when they occur inside a <span></span> pair. If a CSS style is applied to a <span>, and an unclosed paragraph is included in this span, the </span> tag after the paragraph is ignored, and the rest of the document is formatted the same way as the text inside the <span></span> tags. Other browsers recognize the </span> and revert to the main document formatting, even if there is an unmatched <p> tag inside the span.

In the linked webpage, ScienceDirect (a major on-line academic publisher) omits </p> tags in various places. The most important place is just after the article title in the main body of the text (you can find it by searching for articleTitle in the .html file). Because the </p> tag is omitted, Webkit ignores the following </span> tag, and formats the rest of the document in the same style as the article title. (If you manually insert a </p> right before the </span> tag, Webkit will display the page correctly -- reverting to the normal style for the rest of the document body.)

According to the XHTML standard, ScienceDirect should be closing all their paragraphs with </p> tags, so it could be argued that this is their fault and they need to clean up their HTML. However, the linked page does not claim to be XHTML compliant, and earlier HTML standards did indeed allow for unclosed paragraphs. So the choice of how this page should be rendered seems like a gray area. As it is, this page seems like a valid example of somewhat outdated HTML, which Webkit renders poorly. Can Webkit be changed to recognize a </span> tag even if there is an unclosed <p> tag within the span?

[Alexey Proskuryakov]

Created attachment 15542 [details]
test case

[Alexey Proskuryakov]

Confirmed as a difference with Firefox, and because this doesn't look right. I haven't checked with any specs, though.

[David Kilzer (:ddkilzer)]

Not a regression as Safari 2.0.4 (419.3) with original WebKit on Mac OS X 10.4.10 (8R218) also shows this issue.

html5lib agrees with WebKit

(In reply to comment #4)
> html5lib agrees with WebKit
> 

(Referring to the test case (attachment 15542 [details])).

[Adam Barth]

The spec adopted our parsing here.  We don't want to change in the way requested here.