The spec says to dispatch a non-bubbling SVGLoad event: http://www.w3.org/TR/SVG/interact.html#LoadEvent

I'm pretty sure we only fire the 'load' event for <svg> elements right now. This was discussed a bit in bug 552938 (and I think that's where we dropped it for other elements (?)). See in particular bug 552938 Comment 27 and bug 552938 Comment 28.

For some reason I thought that even HTML <img> elements get a load even dispatched, so that listening for it on SVG <image> wouldn't that crazy. If our view is that load shouldn't dispatch anywhere except on the root element of a document, then that's fine.

html images do get an onload so svg images should get the SVG equivalent. I think this needs to be an exception to our svg only rule.

OK, great. As much as possible I'd like SVG's load event dispatching to be consistent with HTML's.

Could this break some existing content? Should we perhaps dispatch both SVGLoad and load for now, and ask SVG WG to drop SVGLoad eventually?

If you do <image onload="something()" .../> with an SVG image, nothing happens at the moment. The only other way to trigger something is addEventListener isn't it? So something doing addEventListener might change. Dispatching both seems reasonable to me. We should ask the SVG WG to drop most of the SVG events. http://www.w3.org/TR/SVG/interact.html#SVGEvents SVGAbort and SVGError should go too and maybe others.

(In reply to comment #7) > If you do <image onload="something()" .../> with an SVG image, nothing happens > at the moment. Oh. I thought onload was supported in svg:img.

It is, just not by us. I'd be in favor of just dispatching 'load' for now.

We do have some special handling in http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsEventListenerManager.cpp#982

I think dispatching both events is the lowest risk option at this point. Converting to just onload risks us not doing the right think like having the correct bubbling and canceling properties.

I really don't want to dispatch SVGXxx events that we don't already dispatch. It will just make it harder to remove the SVGXxx event crap from the spec, and we'll have to live with it and dispatching two events forever. For the most part people will be using 'onload' and 'onerror' attributes and not checking the event name, so I think us using 'load' and 'error' is the better road.

We're already dispatching an SVGLoad event for the outer SVG element. If I remove the code that converts the SVGLoad event to call the onload handler then I'd have to dispatch an ordinary load event to the outer SVG. I'm not sure what the consequences of that would be and I'd be very hesitant therefore to make such a change.

The other alternative is to give up on this for 4.0

Or option c) dispatch load and SVGLoad but only dispatch error and not SVGError just remove the SVGError conversion.

How about just dispatching load to <image>, making <image onload=""> trigger off that, and don't do anything to support addEventListener for SVGLoad? That gets us part of the way to where we want to be and makes the test pass. (None of the SVG 1.1 test suite tests currently use addEventListener to listen for any of the SVG* events.)

I don't think I can implement that without changing the outer SVG element SVGLoad to be load too.

I think doing nothing here would be a better option than dispatching SVGLoad in more cases. Let's go to the group ASAP and try to get agreement to drop the unnecessary SVG* events, then implement that post-FF4. How does that sound?

Comment on attachment 498620 [details] [diff] [review] dispatch both events and support onerror too Doing nothing is always an option :-)

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #18) > I think doing nothing here would be a better option than dispatching SVGLoad > in more cases. > > Let's go to the group ASAP and try to get agreement to drop the unnecessary > SVG* events, then implement that post-FF4. How does that sound? Has this happened?

I raised it - http://lists.w3.org/Archives/Public/www-svg/2011Oct/0046.html. I don't think anything happened though.

Once I get to reviewing/rewriting the Interaction chapter in SVG 2, I'll bring this up again. I've added a note to the chapter to remind myself.

maybe this bug should be morphed into converting SVGxxx events to SVG 2/html events i.e. OnSVGLoad becomes onload, same for onunload, onresize and onscroll. onerror and onabort have been done in bug 500261 already as we never fired SVGError events.

(In reply to Robert Longson from comment #23) > maybe this bug should be morphed into converting SVGxxx events to SVG 2/html > events i.e. > > OnSVGLoad becomes onload, same for onunload, onresize and onscroll. Sounds fine to me.