- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 25 May 2008 22:32:56 +0000 (UTC)
- To: Chris Wilson <Chris.Wilson@microsoft.com>
- Cc: Travis Leithead <travil@windows.microsoft.com>, "public-html@w3.org" <public-html@w3.org>, Harley Rosnow <Harley.Rosnow@microsoft.com>
On Sun, 25 May 2008, Chris Wilson wrote: > > How does this work with progressive rendering? As far as I can tell it is orthogonal to progressive rendering. There are other parts of the parsing algorithm, such as the way to handle bogus content in <table> elements, or misnested formatting tags, that do have minor localised implications on progressive rendering, but in practice the effect is minimal, and can be trivially sidestepped by using mild forms of buffering to decouple the layout from the parsing. In fact the browser that is currently closest to doing what HTML5's parsing algorithm does in those particular areas is also currently amongst the fastest. > So basically you're saying the magic bit is that the parser never hangs > on to the current element, it always looks to the last thing on the > stack to append to? Yup. There are a couple of exceptions related to tables and handling misnested formatting elements, where the DOM is directly manipulated, but the rules in the spec for how to do that define precise behaviour for all the cases that might come up with pathological scripts manipulating the DOM as it is being made by the parser. BTW, I will probably be including the example I gave in the spec at some point when I write up more examples and intro sections, as Travis suggested. Of course, it's no substitute for the exact rules in the spec. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 25 May 2008 22:33:40 UTC