Bug 69994
| Summary: | Reparse invalid XHTML documents as HTML | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Paul Irish <paulirish> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | abarth, code.vineet, mathias, sam |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://codecino.com/lab/yellow-screen-of-death/invalid.xhtml | ||
Paul Irish
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
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.
Mathias Bynens
(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.
Sam Weinig
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.
Adam Barth
I agree. We should either define error handling for XHTML or authors should use HTML if they want error handling.