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

Re: Conditional branch in tree builder based on DOM state

From: Henri Sivonen <hsivonen@iki.fi>
Date: Sun, 4 Jan 2009 16:04:19 +0200
Cc: Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, HTMLWG WG <public-html@w3.org>
Message-Id: <9722F085-D923-4D6D-AB74-F56DA1888756@iki.fi>
To: Maciej Stachowiak <mjs@apple.com>

On Jan 3, 2009, at 19:13, Maciej Stachowiak wrote:

> I'll tentatively agree that iit doesn't sound like a big  
> complication (we do indeed have info besides the node in the stack  
> of open elements). I would have to ask one of our parsing experts to  
> be sure. One thing I wonder about: would this require some new  
> behavior to be implemented for the case where a node has children,  
> but not parser-added children?

The proposed change is checking a hasParserInsertedChildren flag on a  
parser-internal stack node object instead asking the DOM element  
wrapped by the stack node object whether it has children. No new  
behaviors in response to the result of the children check are being  

To get different behavior by checking a parser-internal flag vs.  
querying the live DOM, you'd need to have a situation where a script  
uses DOM APIs to insert stuff into a misnested active formatting  
element that doesn't have any parser-inserted children at that point  
in time, which is unlikely to happen in any remotely-reasonable  
scripting scenario. It seems to me that this would require running the  
script from a timeout/interval and having the parser suspend for event  
loop spin at the right point. Perhaps this case is so narrow anyway  
that we don't even need every implementation to do the children check  
the same way.

Henri Sivonen
Received on Sunday, 4 January 2009 14:16:10 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:41 UTC