- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 02 Jan 2009 09:21:06 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Ian Hickson <ian@hixie.ch>, Henri Sivonen <hsivonen@iki.fi>, HTMLWG WG <public-html@w3.org>
On Jan 2, 2009, at 5:09 AM, Jonas Sicking wrote: > > I agree that this would complicate a parser implementation that > doesn't do speculative parsing while blocked for <script>s. However > the extra complication is very small compared to the complication > added to speculative parsers. Additionally, it does simplify the > interface between the parser and the DOM since with this and the other > change that has been proposed there is no need to read data back from > the DOM. This interface simplification is likely about the same as > adding an extra flag to each node in the tag stack. > > Also, any competitive browser is going to have to do speculative > parsing. The performance gains from doing so is so substantial that > not doing it is not really an option. WebKit trunk does speculative parsing but we don't require anything like this (since we don't care about reusing the tokens - tokenizing is cheap - and we haven't cared so far about multithreaded parsing). In fact it seems to me it would make things more complicated if we were required to distinguish between parser-added and script-added children at parse time. So I think your claim that the requested change will make things better for browsers in general is inaccurate. > > So while you'd have slightly > simpler HTML parsing in consumers other than browsers, you will make > all browsers more complex. The alternative for browsers is likely to > not use a real tokenizer when doing speculative parsing which means > wasting CPU cycles. In our experience this isn't a problem. Regards, Maciej
Received on Friday, 2 January 2009 17:21:48 UTC