All browsers that implement the HTML5 parsing algorithm
should parse HTML the same way, which means your web page
should parse the same way in Firefox 4 and the WebKit
nightly, even if it contains invalid markup.
Parsing perfect HTML5 would be easy, but one of the features of HTML5 spec is that it does that no spec did before: it defines how parsing should work exactly, even in the case of invalid markup. Also, the parser hast to deal with deprecated elements no longer in the spec (such as infamous <font>). I assums most work went into this "how to parse tag soup" part.
Deciding that invalid markup should work would be the wrong turn I alluded to.
It would have been very easy to drop all the back compat bs by saying "An HTML5 document is one that begins with the 6 bytes '<html5' and if the document is invalid, reject it. Anything else, parse however you want." Browsers that support HTML5 add text/html5 to the Accept header.
Alas, your six bytes would drop older browsers into quirks mode, which makes is not nice. The only reason HTML5 has doctype at all is because it forces browsers into standards mode.
What you propose sounds a bit like the way XHTML2 was intended to go, we know how that ended.
There is and will be tons of invalid documents on the web—the wast majority of it, so browser rejecting them has no future, the blame will be on the browser, not the authors. Having at least some consistency in dealing with invalid documents is A Good Thing™.
So, how many different parsers did you want to see in the browser again?
You'd still need to support HTML4 somewhere. Supporting HTML5 separately just means duplicating the common parts of the parser. The simplicity boat has already sailed.
They're extremely similar. You don't get an explosion of code size. Unless you're suggesting that HTML5 should also be radically different syntactically as well?
I'm suggesting that a HTML4 parser that has complex recovery code, and a mostly-copy-and-paste HTML5 parser that doesn't isn't a big win.
Browsers are going to have a complex, ugly, recovery-enabled parser in them either way, and the effort to add HTML5 to the recovery-enabled parser isn't very big, comparatively speaking.
Not really true in this case. WebKit's previous HTML parser is similar in complexity to the HTML5 parser. Adding a second HTML parser would have been more code, more complexity, and a more complex test matrix.
The problem with this approach is the same problem people serving XHTML as application/xhtml+xml ran into: You don't control your page any more these days.
If you allow people to leave comments on your page or if you are serving ads, you lose a bit of control in what gets put on a particular page of yours.
In case of comments you could try and sanitize them, but with ads that's hardly possible.
