Bug 20696 - WebKit fails to recognize XHTML <a id="blah" /> as a closed tag
Summary: WebKit fails to recognize XHTML <a id="blah" /> as a closed tag
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: All Linux
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2008-09-07 01:49 PDT by Bernhard Rosenkraenzer
Modified: 2008-09-13 09:02 PDT (History)
2 users (show)

See Also:

Test case (547 bytes, text/html)
2008-09-07 01:51 PDT, Bernhard Rosenkraenzer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Rosenkraenzer 2008-09-07 01:49:23 PDT
WebKit thinks <a id="blah" /> is an opened tag that doesn't have a matching closing tag.

The attached test shows the problem.
Comment 1 Bernhard Rosenkraenzer 2008-09-07 01:51:06 PDT
Created attachment 23225 [details]
Test case

The attached test xhtml file shows the problem - test1 shows up as test2's parent when it should be its sibling.
Comment 2 Mark Rowe (bdash) 2008-09-07 02:21:11 PDT
Your MIME type is causing the page to be parsed as HTML, not XHTML.  That said, it's not valid XHTML either.  Making the minor tweak necessary to cause it to parse as XHTML and serving it with the correct MIME type leads to it displaying "bug not found" as one would expect.
Comment 3 Mark Rowe (bdash) 2008-09-07 02:25:55 PDT
I believe that WebKit's treatment as the document served as text/html is correct per the HTML 5 parsing algorithm.  Pasting the source into the HTML 5 Live DOM Viewer at <http://livedom.validator.nu/>, you can see that the DOM places test2 inside test1.
Comment 4 Dave Hyatt 2008-09-07 11:15:54 PDT
This is invalid.  Serve your page with an XML or XHTML MIME type.
Comment 5 Bernhard Rosenkraenzer 2008-09-09 13:05:16 PDT
I'd argue that <?xml and XHTML DOCTYPE should be a good enough indication that the document should be treated as XHTML (maybe with a fallback to the current behavior if the document turns out to be not well-formed XML) - especially in a context where a mime type is not available at all (e.g. reading the file from the filesystem or even writing it directly into the WebKit widget).

The test case works correctly in Firefox regardless of the way it is read.
Comment 6 Alexey Proskuryakov 2008-09-13 09:02:26 PDT
Both Safari and Firefox treat this document as HTML. There are many reasons for HTTP headers to prevail over XML declaration, so no major browser treats content transferred as text/html as XHMTL.

This document is rendered in Firefox as "expected" because Firefox follows different rules for processing invalid markup. WebKit matches HTML5, which you can confirm yourself by comparing output of <http://software.hixie.ch/utilities/js/live-dom-viewer/> and <http://james.html5.org/parsetree.html> in both browsers.

You can also see that Firefox will render the document the same if you remove the ending slash, as it is ignored anyway.