69994 2011-10-12 20:50:50 -0700 Reparse invalid XHTML documents as HTML 2011-10-13 14:13:22 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX http://codecino.com/lab/yellow-screen-of-death/invalid.xhtml P2 Normal --- 0 paulirish webkit-unassigned abarth code.vineet mathias sam oldest_to_newest 482986 0 paulirish 2011-10-12 20:50:50 -0700 Opera recently announced they were ending draconian error handling of invalid XHTML documents. http://my.opera.com/ODIN/blog/2011/09/28/no-more-xml-parsing-failed-errors If a document is XHTML, served as application/xhtml+xml, and is not wellformed, then in Opera's case, they will reparse as HTML. WebKit should do the same. Draconian error handling is fine for the developer, but users gain no benefit at all. They want to see the content at a site, not a "Not wellformed Document" error page. It's best for users to route XHTML parsing errors to the inspector and deliver the content to the screen. 483333 1 ap 2011-10-13 11:16:25 -0700 It's still not clear to me what's the benefit here. If the developer wants to use HTML, why not just serve the content as HTML? Second attempt at parsing will just cause proliferation of broken content that will forever be slow to display, ultimately hurting users. 483337 2 mathias 2011-10-13 11:24:56 -0700 (In reply to comment #1) > Second attempt at parsing will just cause proliferation of broken content that will forever be slow to display, ultimately hurting users. Slow to display > displaying nothing at all, IMHO. 483464 3 sam 2011-10-13 14:03:09 -0700 I also don't really get the reason for doing this. If we wanted to do something like this, defining error-handing for XML (XML5!) seems like the way to go. 483472 4 abarth 2011-10-13 14:13:22 -0700 I agree. We should either define error handling for XHTML or authors should use HTML if they want error handling.