Re: Black-box equivalence of parsing fragments directly into context node

On Nov 27, 2008, at 00:54, Jonas Sicking wrote:

> Henri Sivonen wrote:
>> On Nov 26, 2008, at 23:28, Jonas Sicking wrote:
>>
>>> Why couldn't the spec instead say to use the ownerDocument of the  
>>> context node (like Henri is suggesting) and parse into a  
>>> documentFragment node? I.e. why do we need the new Document node  
>>> and the new <html> node?
>> Why is there even a need for parsing into a document fragment?  
>> Would mutation events or something of that nature go wrong if  
>> parsing directly into the context node?
>
> If we ensure that no events fire during the parsing then parsing  
> directly into the context node should be fine.

This seems like it's still worth pursuing, considering that the tree  
builder--per spec--shouldn't fire mutation events for insertions  
performed by the parser, so the behavior should be that mutation  
events don't fire during the parse anyway.

> Mutation events are always a pain (and i'm very seriously  
> considering dropping support for them in gecko) but largely undefined.

Aren't there accessibility dependencies on mutation events by now?

> So we can simply stay silent on them for now, or put in something  
> informative, but talk with the webapps wg so that when they define  
> them ensure that they fire after all parsing is done and all nodes  
> are inserted. I.e. setting innerHTML should be considered a  
> 'compound operation'.
...
> I'm not sure if there are other things that can cause events to  
> fire. For example, does 'change' events fire when parsing a <select>  
> with multiple options selected? If so we'd need to define that such  
> events don't fire until after the innerHTML setting is fully done.

Is there a general mechanism for deferring content-related events?

>> I did notice Boris' points about <base> and the form pointer in  
>> mozilla.dev.platform. However, wouldn't it be feasible to set the  
>> form pointer to the nearest form parent of the context node
>
> Does anything need to be set at all? Normally during DOM operations  
> form-controls are only associated with ancestor <form> elements. Why  
> wouldn't the same thing be done here?

Actually, that might not be the problem but there's the case of nested  
forms themselves:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cbody%3E%3Cform%20id%3Da%3Efoo%3C%2Fform%3E%3Cscript%3Edocument.getElementsByTagName('form')%5B0%5D.innerHTML%20%3D%20%22%3Cform%20id%3Db%3Ebar%3C%2Fform%3E%22%3B%3C%2Fscript%3E

Firefox is aware of the outer form and throws away the inner one.  
WebKit, Opera and HTML5 as currently drafted are unaware of the outer  
form and create a tree with the inner form as the child of the outer.  
IE8 experiences an error.

Since WebKit and Opera already have the HTML5 behavior and IE8 fails  
to have either behavior, I guess going with the spec is OK.

>> and not process <base> in the fragment mode?
>
> Why would you do anything special for <base> at all? I'd think that  
> if setting .innerHTML results in one or more <base> elements getting  
> inserted, you'd just act the same way as if they had been inserted  
> using .appendChild.
>
>> Presumably, XLink autoloads and the load event for SVG fragments  
>> would have to be suppressed, but that's not worse than having to  
>> mark scripts as already executed.
>
> Yeah. IMHO both those features should be removed from the web  
> platform.

Speaking of the load event for SVG subtrees: During normal parse, when  
the load event for an <svg> element fires, can a handler react to it  
before there has been an event loop spin? That is, should I treat the  
firing of that event as a potential trigger of document.write()  
entering the parser?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 27 November 2008 10:38:32 UTC