Re: Substitute for onload event in XSLT-generated graphics

Chris Lilley wrote:
>   The event is triggered at the point at which the user agent has
>   fully parsed the element and its descendants and is ready to act
>   appropriately upon that element, such as being ready to render the
>   element to the target device. Referenced external resources that are
>   required must be loaded, parsed and ready to render before the event
>   is triggered. Optional external resources are not required to be
>   ready for the event to be triggered.
> 
>   SVGLoad events do not bubble and are not cancelable.
> 
>   http://dev.w3.org/SVG/profiles/1.1F2/publish/interact.html#SVGEvents
> 
> so the intent is 'the element is all ready to go' but it is expressed
> in terms of parsing.
> 
> Its reasonable for an in-browser XSLT implemention to create a DOM
> representation of the result tree directly rather than generating a
> serialised result tree and then parsing it. The definition of the load
> event should clarify that SVGLoad is fired in this case.

Fired at what point?  When the result tree is created?  Or when it's 
embedded into its final target document (which is a good bit later)? 
Basically, all that happens here in Gecko is a TransformToDocument into 
a new document, then an adoption of that new document into an existing 
Window.  As you note, this is a reasonable behavior for an XSLT 
implementation.  Perhaps the adoption step should fire load events?  In 
What order?  What should happen if those events modify the DOM?

> This was discussed at the 26 August SVG WG telcon. We observed that
> some browsers (Safari and Opera) do throw a load event, so the upper
> and lower subtests look the same in your test case. Firefox (various
> versions up to 3.6a1) did not throw a load event.
> 
> XSLT does not define the processing of the result tree and says
> its application dependent how its loaded
> http://www.w3.org/TR/2009/PER-xslt20-20090421/#result-trees

Yep.

> In general we felt that, for in-browser XSLT generating SVG, load
> should throw, but are investigating further. We are also doing similar
> testing for XSLT which generates HTML. Anyway, just to say that your
> report was picked up and is being acted on.

I would be very interested in a clear definition of SVG's load event 
that would actually trigger in the situation I describe above.  Thanks 
for looking into this!

-Boris

Received on Wednesday, 26 August 2009 10:15:03 UTC