W3C home > Mailing lists > Public > www-svg@w3.org > July 2010

Re: load event in interact-events-01-b.svg and SVG 2.0 - ISSUE-2254

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 21 Jul 2010 11:09:02 +0300
Cc: www-svg <www-svg@w3.org>
Message-Id: <9250F2C3-2AA4-4281-8AFE-571C8EEDCA80@iki.fi>
To: Erik Dahlstrom <ed@opera.com>
On Jul 20, 2010, at 22:34, Erik Dahlstrom wrote:

> On Tue, 20 Jul 2010 12:50:58 +0200, Henri Sivonen <hsivonen@iki.fi> wrote:
> 
>> For reasons covered in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=552938#c27
>> and
>> https://bugzilla.mozilla.org/show_bug.cgi?id=552938#c24
>> Firefox as of 4.0 beta 2 no longer supports the SVG load event on arbitrary SVG elements. It's now only supported on <svg>.
>> 
>> Could the SVG WG, please, remove the load event from non-<svg> elements in SVG 2.0 (or even earlier spec revisions) and retire the testcase
>> http://www.w3.org/Graphics/SVG/Test/20061213/svggen/interact-events-01-b.svg
>> that relies on the load event firing on non-<svg> elements?
> 
> I agree that that particular testcase isn't really doing a good job of showing what load events should be used for.
> 
> I don't think "removing load events" from all non-<svg> elements was what the WG discussed in the past relating to this issue.
> In particular, why should there be no load event on svg elements that can have external resources?

That would be a different kind of load event from the load event SVG has now.

> Just going by what HTML5 says for the <html:script> element for example:
> [[ If the script is from an external file, fire a simple event named load at the script element. ]]
> 
> It seems reasonable to say that if any element in svg loads an external resource then it should fire a simple load event, same as for <html:img>, <html:script> etc.

That would seem reasonable, yes. However, that's very different from having the load event on every element or having the load event depend on the children of the element loading external resources.

>> Also, the event is now async in Firefox. It was already async in Opera.
> 
> Async as in not fired at parse time (if the resource was available then, or if there was no resource referenced)?

Async as in fired from the event loop possibly before the parser has finished parsing the document that contains the <svg> subtree.

> Async as in fired whenever the resource actually loads?

Firefox has never made SVG load events actually wait for resource loads, and it isn't doing so now, either. While I can see merit in introducing HTML-like load events for images and scripts, I suspect it might be problematic to defer the load event of the <svg> element on those. I can see why it would be logical to defer it, but I haven't thought through the implementation issues.

>> Could you also, please, specify it to be async.
> 
> Where in the spec is it said (or implied) that it's not async?

If there are no subresources to wait for, one might argue that the spec currently doesn't sufficiently say that the event is not sync.

>> If I need to file this into a tracking system to have this consider, please advise me which tracking system I should use.
> 
> It is already tracked as a SVG 2.0 issue, http://www.w3.org/Graphics/SVG/WG/track/issues/2254.

Thanks.

> If you wish to speed up the handling of that issue, it would help if there was one or more comprehensive tests. Given that Mozilla has open bugs on this, I'd assume there are some testcases relating to this. Could Mozilla contribute such tests to the svg testsuite?

We have a couple of tests testing that the event fires on <svg>, but currently we don't have more comprehensive tests testing the absence of the event in other cases. I'll look into this.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 21 July 2010 08:09:36 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:45 GMT