- From: Jennifer Yu <Jennifer.Yu@microsoft.com>
- Date: Sat, 27 Mar 2010 20:11:36 +0000
- To: "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <B529221E3168C74E9A2E9711090735252DE1DF19@TK5EX14MBXC133.redmond.corp.microsoft.>
I would like to add to Patrick's question about SVG events. It seems as though SVG events will eventually be consolidated with the corresponding DOM3 events. However, I'd still like to address a couple of details in the current SVG spec and get a better understanding of how they should operate. SVGError and SVGAbort: According to the spec (1.1 2nd edition), the SVGError and SVGAbort events bubble. Let's take the following markup: <svg onerror="alert('oops');"> <g> <image xlink:href="non-existent-file.jpg"/> </g> </svg> If non-existent-file.jpg cannot be found, it seems pretty clear that <image> will fire an SVGError event. However, what about <g> and <svg>? Should they then also each fire an SVGError event? Or SVGLoad? It doesn't seem very useful for the event handler to catch the SVGError 3 times because of event bubbling. At the same time, the description for SVGLoad states that "Referenced external resources that are required must be loaded, parsed, and ready to render before the event is triggered." Additionally, should SVGError fire for situations other than the failed loading of an external resource? SVGUnload: With the ability for multiple SVG document fragments to occur inline in an XHTML/HTML document, the current description of SVGUnload implies that SVGUnload would fire once for each non-nested SVG document fragment. It seems more appropriate for SVGUnload to fire for an SVG document fragment if it is the root node of the document. Thanks, Jen
Received on Monday, 29 March 2010 14:43:56 UTC