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

On Dec 2, 2008, at 12:16, Ian Hickson wrote:

>>> On Wed, 26 Nov 2008, Boris Zbarsky wrote:
>>>>
>>>> From a spec point of view the only obvious issue I see here is  
>>>> that the
>>>> mutation event behavior means the parser needs to take pains to  
>>>> produce
>>>> the same results as would be produced by the currently-specified
>>>> algorithm even in cases when mutation events rearrange the DOM.
>>>
>>> Surely we don't want any mutation events firing during innerHTML.
>>>
>>> The spec currently says:
>>>
>>> # DOM mutation events must not fire for changes caused by the UA  
>>> parsing
>>> # the document. (Conceptually, the parser is not mutating the DOM,  
>>> it is
>>> # constructing it.) This includes the parsing of any content  
>>> inserted
>>> # using document.write() and document.writeln() calls.
>>
>> But the act of inserting the fragment into the document is  
>> conceptually a
>> scripted mutation, isn't it?
>
> Once mutation events are more stable, if we want them to fire for  
> these
> mutations, then we can add them back, with a clear definition of how  
> they
> work. That's dependent on what DOM3 Events ends up saying.

http://groups.google.com/group/mozilla.dev.platform/msg/ddb57992f7553346
and
http://groups.google.com/group/mozilla.dev.platform/msg/d36577d78c21372c
indicate that mutation events need to fire upon fragment insertion.

>>> On Thu, 27 Nov 2008, Henri Sivonen wrote:
>>>>
>>>> For efficient buffering, it's important for the parser to know when
>>>> it needs to drive buffers into a safe point so that  
>>>> document.write()
>>>> can insert into the stream. So far, at least my assumption has been
>>>> that scripts can only execute as a side effect of a parser action
>>>> when a <script> element (either HTML or SVG) is popped off the
>>>> stack. Now it has turned out that scripts can execute as a side
>>>> effect of a parser action also when an <svg> element is popped off
>>>> the stack.
>>>
>>> Ew, that seems highly problematic. Where is this defined?
>>
>> http://www.w3.org/TR/SVG/interact.html#LoadEvent Now I notice that  
>> it's
>> even worse than <svg onload>: It's onload on any element in the SVG
>> namespace.
>
> I don't see where the actual normative requirement is. Could you
> elaborate?

I don't see a normative requirement, either.

> Even based on the (requirement-free) descriptive sentence for  
> SVGLoad in
> that table, there's nothing that says it should be synchronous. If
> anything, the dependence on other resources implies it can't be.

Gecko's XML tree builder dispatches the event synchronously (based on  
looking at the stack in gdb).

> I can mention the SVGLoad event explicitly in the definition of the  
> event
> loop if that would help, but really I'd much rather the SVG spec was
> written to actually define how this is really supposed to work.

I agree.

I'm not trying to advocate even having the event. I'm just noting that  
I found a non-<script> place where scripts can execute as a  
synchronous side effect of the XML parse at least in Gecko, and the  
case is relevant to text/html parsing to the extent the two  
serializations are expected to have feature parity.

>> (On its face, blowing away the document seems more complex than  
>> making
>> document.write a no-op if called from an SVG onload handler. I need  
>> to
>> study existing cases of blowing away the document more carefully.)
>
> Blowing away the document happens because document.open() is  
> implicitly
> called. It can always be explicitly called. I don't think we want to  
> be
> adding more ways that document.open() can react here.

Ah. You've made Opera/IE7 behavior normative instead of the Gecko/ 
WebKit behavior. (IE8 beta2 hangs when trying my test case: http://hsivonen.iki.fi/test/moz/write-from-timeout2.html 
  )

Have I understood correctly that the insertion point can be defined  
only at moments when the parser executes a script upon </script> close  
tag?

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

Received on Tuesday, 2 December 2008 17:26:05 UTC