They won't do it for application/xhtml+xml, so if you want to see this in action, try sending your page as text/html and then application/xhtml+xml. You'll notice that the XML-based page seems glacial.
(Why does this happen? Who knows. I have been using streaming XML parsers since like 1990...)
But who cares? The browser isn't validating HTML as it's rendering it, otherwise the internet would be one big blank page.
But that's the big difference isn't it? Browsers fix html as they go, but they blow up on XML (as mandated by the XML spec).
What would be weirder, seeing the page either render fully or blow up, or seeing a page start rendering and then at some point be replaced by an error message?
Of course ideally it would start rendering and keep rendering, never blowing up, but that's not really allowed in XML.
Who says the page has to be replaced? Webkit and Opera (IIRC) happily render the page up to the first error that they encounter.
Gecko's decision to do the YSOD was a bad one.
That shocks me quite a bit. This definitely didn't use to be the case for Safari, early versions implemented draconian XML error handling and refused to display non-well-formed documents.
> Gecko's decision to do the YSOD was a bad one.
Meh.
> Meh.
There were many circumstances that prevented the adoption of XHTML-as-XHTML. One of them was the fact that your users would get a cryptic error page, with no context, if something went wrong.
What Webkit does is much less threatening.