WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
20696
WebKit fails to recognize XHTML <a id="blah" /> as a closed tag
https://bugs.webkit.org/show_bug.cgi?id=20696
Summary
WebKit fails to recognize XHTML <a id="blah" /> as a closed tag
Bernhard Rosenkraenzer
Reported
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.
Attachments
Test case
(547 bytes, text/html)
2008-09-07 01:51 PDT
,
Bernhard Rosenkraenzer
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Bernhard Rosenkraenzer
Comment 1
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.
Mark Rowe (bdash)
Comment 2
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.
Mark Rowe (bdash)
Comment 3
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.
Dave Hyatt
Comment 4
2008-09-07 11:15:54 PDT
This is invalid. Serve your page with an XML or XHTML MIME type.
Bernhard Rosenkraenzer
Comment 5
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.
Alexey Proskuryakov
Comment 6
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug