4 ms·
Pay attention to this part: All browsers that implement the HTML5 parsing algorithm should parse HTML the same way, which means your web page should pars
by rimantas 16y ago
Pay attention to this part:
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.
- tedunangst 16y agoDeciding 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.
- ori_b 16y agoSo, 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.
- tedunangst 16y agoAddition is simpler than combination. HTML4 + HTML5 < HTML4 * HTML5
- ori_b 16y agoThey'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?
- tedunangst 16y agoI'm suggesting that a strict HTML5 parser that doesn't have complex recovery code is radically simpler than one that does.
- ori_b 16y agoI'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.
- othermaciej 16y agoNot 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.
- Retric 16y agoComplexity does not increase linearly with number of lines of code. 110k lines can easly be 5x as complex as 100k lines of code.
- sesqu 16y ago1 + 1 > 1 * 1
- deleted 16y ago[deleted]
- rimantas 16y agoAlas, 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™.
- pilif 16y agoThe 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.