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

Ian Hickson wrote:
> On Tue, 2 Dec 2008, Henri Sivonen wrote:
>> The spec is clear that the act of parsing the fragment doesn't cause 
>> mutation events to fire. However, the spec isn't clear on whether 
>> mutation events should fire for the act of inserting the fragment into 
>> the main document.
> 
> Clarified.

Ian, I can't seem to find the clarified text in 
<http://www.w3.org/html/wg/html5/>.  Where should I be looking?

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

For what it's worth, I agree with Ian that the SVG spec doesn't really 
clearly define the behavior here.  As far as external resources go, 
though, by default none are required in SVG (see discussion about that 
exact issue in <https://bugzilla.mozilla.org/show_bug.cgi?id=252631>).

That said, discussion on www-svg (say in the thread starting at 
<http://lists.w3.org/Archives/Public/www-svg/2002Nov/0002.html>) makes 
it clear that SVGLoad is not fully async, and that in particular it must 
fire before painting (and presumably layout) happens in various cases. 
I have no idea _why_ such a requirement is in place, but it's there.

I suspect that to really proceed here the SVG working group would need to:

1)  Investigate when current UAs fire this event.
2)  If they do this interoperably at parse-close-tag time, decide
     whether current content depends on this behavior.
3)  Specify more clearly when the event can be fired with respect to
     the content model.  Such a definition would at the very least need
     to define whether, given

    <svg xmlns="http://www.w3.org/2000/svg">
      <svg onload="alert(document.getElementsByTagName('svg').length)"/>
      <svg/>
    </svg>

     the alert is allowed to show 3.  It would also need to more clearly
     specify how the timing of the event is related to layout (as
     opposed to actual on-screen bit-blitting, which is what it seems
     to talk about right now).

-Boris

Received on Tuesday, 2 December 2008 15:27:58 UTC