W3C home > Mailing lists > Public > public-html@w3.org > January 2009

Re: Conditional branch in tree builder based on DOM state

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 02 Jan 2009 09:21:06 -0800
Cc: Ian Hickson <ian@hixie.ch>, Henri Sivonen <hsivonen@iki.fi>, HTMLWG WG <public-html@w3.org>
Message-id: <FC3482A0-B3E6-453A-B0A7-497D0CD4AE4C@apple.com>
To: Jonas Sicking <jonas@sicking.cc>


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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:00 UTC