W3C home > Mailing lists > Public > public-html@w3.org > June 2008

Re: Re-entrant invocation of the tree builder

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 17 Jun 2008 20:58:12 +0000 (UTC)
To: Henri Sivonen <hsivonen@iki.fi>
Cc: "public-html@w3.org WG" <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0806172030350.6527@hixie.dreamhostps.com>

On Tue, 17 Jun 2008, Henri Sivonen wrote:
> 
> Would doing this break something crucial compared to actually 
> re-entering the tree builder before it has returned from handling the 
> script-related tokens?

I think you can implement it the way you describe by moving the logic for 
<script> tokens into the driver, basically. You'll need a stack to handle 
the changes to the insertion position.


> Aside: I find the concept of "insertion point" in a stream to be harder 
> to track than a concept of a stack of pending streams where each 
> document.write() pushes a new stream onto the pending stack.

I don't know if a stack can be equivalent to the insertion point concept. 
It depends whether you keep track of how much you have tokenised for each 
item in your stack, and whether you can append to an item on the stack.

Consider:

   <script>
     document.write("a<script src=b><\/script>c");
     document.write("d");
   </script>...

When the inline script is about to be done executing, the input stream 
looks like:

                                   v  v
   ...ript>a<script src=b></script> cd ...
                                   ^  ^
                                   T  I

...where T is the tokeniser's position ("c" is the "next input character") 
and I is the insertion point. However as soon as it is done executing the 
UA will pause for 'b', and if b does a document.write() it'll go where "T" 
is, not where "I" is.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 17 June 2008 20:58:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:18 GMT