W3C home > Mailing lists > Public > www-svg@w3.org > August 2009

Re: Substitute for onload event in XSLT-generated graphics

From: Chris Lilley <chris@w3.org>
Date: Wed, 26 Aug 2009 10:17:21 +0200
Message-ID: <202428862.20090826101721@w3.org>
To: Rüdiger Plantiko <ruediger.plantiko@astrotexte.ch>
CC: www-svg@w3.org
On Tuesday, August 25, 2009, 9:05:12 AM, Rüdiger wrote:

RP> Hi,

RP> the SVG scripting specification defines that the onload event
RP> handler is *only called for parsed nodes*.

Thanks for the report. The SVG spec says:


  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.


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.

RP>  A similar event for
RP> XSLT-generated graphics should be available as a substitute, since
RP> they are not parsed.

RP> See my example page
RP> http://www.astrotexte.ch/sources/svgonload.html which
RP> illustrates the problem, and the textual description of the problem in
RP> https://bugzilla.mozilla.org/show_bug.cgi?id=386856 – they were right to
RP> refuse this bug.

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

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.

RP> Basically, I want to separate data layer and presentation layer by keeping
RP> only the data in the XML and doing the processing of the graphics in an
RP> XSL style sheet. Since XSLT is ill-suited for trigonometric calculations
RP> and similar operations, a scripting language has to be invoked during this
RP> processing.

Sure, that's a reasonable approach.

RP> This can only work, however, if there exists an appropriate substitute for
RP> the onload event or if the definition of onload is extended to this
RP> context.

We are tending more to the second option, ie clarifying that the load
event is thrown when SVG is generated in-browser by XSLT, since that
seems more useful than a new event and is in line with some existing

 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Wednesday, 26 August 2009 08:17:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:18 UTC