User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:18.104.22.168) Gecko/20070515 Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:126.96.36.199) Gecko/20070515 Firefox/188.8.131.52 When embedding an SVG graphic into an HTML Site with an object tag as below, with a XSL-styled XML document as source, the onload event handler is not called . If, however, the result tree which is a valid SVG document, is produced by an external XSLT processor and embedded the same way into the HTML page, the onload handler will be called and the graphic will be displayed correctly. ... <object data="horo.xml" type="image/svg+xml" width="400" height="400"> <param name="src" value="horo.xml"> [no SVG viewer installed... blabla...] </object> ... http://www.astrotexte.ch/sources/svgonload.html contains a reproduceable example and all the necessary files. Reproducible: Always Steps to Reproduce: 1. Create a sample XML document in an arbitrary format 2. Create an XSLT transformation which generates an SVG graphic from it. The graphic contains an onload-handler to manipulate the SVG tree depending on the XML source document (1). 3. Use the <?xml-stylesheet... ?> processing instruction to associate (2) with (1) 4. Create a HTML page and embed the XML-document into it as SVG-graphic, using the <object> tag. 5. When calling the HTML page, observe that the onload handler is not called and therefore the graphic doesn't render as expected. 6. However, when transforming the XML document externally, e.g. with Perl's XML::XSLT processor, and embedding the result into the page using the <object> tag as above, observe that the onload handler is called and the graphic renders as expected. http://www.astrotexte.ch/sources/svgonload.html contains a reproduceable example and all the necessary files. Actual Results: onload handler is not called => graphic not rendered properly Expected Results: onload handler should be called
The SVG specification defines the onload handler as being called when the element is parsed. In this case, there is no parsing going on: you're directly synthesizing SVG DOM nodes. You'd get the same effect if you built the DOM tree involved using createElementNS. You might want to raise this with the SVG working group...
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. Firefox (various versions up to 3.6a1) did not. 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 In general we felt that load should throw, but are investigating further. Also doing similar testing for XSLT which generates HTML. Anyway, just to say that your report was picked up and is being acted on.
Chris, just to be clear, XSLT has two primary modes of operation. Either DOM nodes are produced directly as the output of the transform, or they're produced, serialized, then parsed. Per the current definitions in the SVG spec, the latter would fire load events. Some browser XSLT engines operate in the latter mode some or all the time. In the former mode, the operation really does look just like building a DOM with createElementNS then adopting it into another document. Thanks for looking into this.
Hi Boris and Chris, thank you for these deep and detailed inside informations on SVG as well as on the Firefox implementation. Persopnally, I would agree that re-using the existing onload event in the XSLT case is better than providing an extra event for that case. But you both will agree with me about the necessity of such an event - whatever decision the W3C SVG group will make. With best regards, Rüdiger
HTML 5 doesn't say anything about how to treat the result of xml-stylesheet-begotten HTML documents either, but Firefox, Opera and WebKit all dispatch a load event: http://mcc.id.au/temp/2009/xslt-load-event-html.xml For SVG documents, Opera and WebKit dispatch it: http://mcc.id.au/temp/2009/xslt-load-event-svg.xml So I think despite the lack of spec treatment it would at least be consistent with HTML to dispatch it for SVG documents created using XSLT.
In the former case, the event is fired on the window. We do fire it on the window for the SVG case too; if your script were registering a handler for the window load event, you would see it. But it's not doing that; unlike onload on <body> in HTML (which HTML5 DOES define to add an event handler to the window), onload on the root <svg> in SVG just listens for the load event on the element. So we're already being consistent in terms of HTML and SVG here as far as the events we dispatch; the two are just not consistent with each other as far as what event listeners they register. Opera and Webkit reparse their XSLT output last I checked, so there is no spec issue.
#7 Boris, could you expand on what you mean in this comment? I have read the complete comments. in particular it seems to my reading that you may at least, be saying that in the case of svg only, that is not using object in html; you believe the onload event is fired, however my Bug 493585 which has a testcase, is also broken, and I cannot quite understand the issue, most particularly as Safari and Opera work fine. in my simple understanding, there is no svg document until after the xslt transformation, and so there should be an onload event that is used by script.
> however my Bug 493585 which has a testcase, is also broken You really need to read comment 7 again... To repeat, Gecko fires a load event on the _window_ in that case. You aren't putting an event handler on the window. So you don't see the load event. The XSLT behavior in Safari and Opera is different because last I checked they produce a _string_ and parse it. SVG _element_ load events fire during parsing. All of which I said before.
Hi Boris, the only unsatisfactory point with your solution (which happily means for Firefox to keep everything as it was in 2007 when I submitted this report) is a layer problem: If an HTML page embeds an SVG graphic - why should the SVG graphic itself know or care about this? Why should the SVG graphic register its load handler on "window:onload" which does not belong to the graphic itself? On the other hand, the example shows that the SVG graphic itself needs a load event. You could argue that it's in the responsibility of the HTML page to call the load handler for the embedded SVG graphics. But again, the example shows that this handler belongs to the graphics itself and not to the environment in which it is embedded. Why should the HTML page care about the inner structure of a graphic (in particular about its special necessity of being finished by a load handler) - the HTML page only wants to embed it. If it contains, say, 20 images in different formats, the markup should only contain the references to these images, but not further graphic-format-specific details for rendering the images properly. Regards, Rüdiger
> Why should the SVG graphic register its load handler on "window:onload" which > does not belong to the graphic itself? It shouldn't, nor does it. > On the other hand, the example shows that the SVG graphic itself needs a load > event. Why? The SVG spec defines load events that fire during parsing. They don't fire when you create SVG images in some other way (say via the DOM's createElement and appendChild). If you think that should change, the right place to bring it up is the SVG working group.