> 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.
> 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?
Who says the page has to be replaced? Webkit and Opera (IIRC) happily render the page up to the first error that they encounter.
> Who says the page has to be replaced? Webkit and Opera (IIRC) happily render the page up to the first error that they encounter.
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.
It's still draconian error handling, all the spec says is that you have to stop parsing and notify the user.
> 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.
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.