W3C home > Mailing lists > Public > www-svg@w3.org > March 2007

Re: SVG12: Confusing SVGLoad bubbling behavior note

From: Doug Schepers <doug.schepers@vectoreal.com>
Date: Tue, 27 Mar 2007 09:50:25 -0400
Message-ID: <46092121.3050101@vectoreal.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Jonathan Watt <jwatt@jwatt.org>, www-svg@w3.org

Hi, Jonathan-

Bjoern Hoehrmann wrote:
> * Jonathan Watt wrote:
>> It has been my understanding that the text being replaced (deliberately for 
>> performance reasons) meant that SVGLoad events have neither a capture nor a 
>> bubble phase, but only an "at target" phase. Since SVGLoad events are dispatched 
>> to _all_ element in the document - and SVG documents can be very large - 
>> changing the specification to essentially say that SVGLoad events have a capture 
>> phase has serious implications on the length of time it will take for SVG 
>> documents to load.
> In the DOM Event Flow all events accomplish the capture phase. There is
> no reason why this would have considerable performance impact, you can,
> for example, memorize whether there are any capturing SVGLoad listeners
> in the document and if not, completely skip the event phase, or perform
> other optimizations. If you truly believe the DOM Event Flow should be
> so that some events accomplish the capture phase and others do not,
> please send a more detailed comment to public-webapi@w3.org making your
> case.

Bjoern makes a lot of sense here.  I talked about this issue at length 
with Olli Pettay of Mozilla, and he expressed concern that the text we 
are replacing implied that there was no capture phase; since all other 
events have a capture phase, he opined that it would be an 
implementation burden to make SVGLoad behave differently.  In light of 
this feedback, I would be reluctant to omit the capture phase.

In any case, Bjoern was right in his original comment that the text was 
unclear about capture phrase (and I am not certain what the intent was 
myself).  This new text will lead to better interop.

That said, if you discover in implementing it that this truly causes a 
performance hit, and that there isn't a way around it in your 
architecture, let us know and we will reopen this issue to public feedback.


Research and Standards Engineer
6th Sense Analytics
mobile: 919.824.5482
Received on Tuesday, 27 March 2007 13:50:43 UTC

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