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

On Nov 26, 2008, at 23:28, Jonas Sicking wrote:

> Henri Sivonen wrote:
>> I'm considering implementing HTML5 innerHTML setting in Gecko by  
>> using the owner document of the context node as the document seen  
>> by the parser and by sticking the context node as the first node on  
>> the stack (but masking its name to show "html" to the tree builder  
>> in order to avoid breaking the fragment algorithm assertions) and  
>> by then running the fragment parsing algorithm without returning to  
>> the event loop until done. The context node would be in the tree  
>> for the entire time. I'd deflect attempts to add more attributes to  
>> the root node upon stray <html> tag.
>> Is there a reason why the spec doesn't prescribe this? Why does the  
>> spec specify parsing into another document first and then moving  
>> the nodes over? Is what I described above not black-box equivalent  
>> to the steps that the spec prescribes?
>
> What do you mean by "masking its name to show 'html'"?

I meant creating a parser-internal stack node object that wraps the  
real context node for passing to concrete tree builder methods but  
shows the local name for "html" for abstract tree builder-internal  
comparisons. However, I now see that my fragment case compares don't  
compare the local name anyway (even though the spec talks about the  
"html" node) and instead compare for stack position 0, so masking the  
name is moot.

> 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?

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 and not process  
<base> in the fragment mode? 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.

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

Received on Wednesday, 26 November 2008 21:55:35 UTC