Re: Should the base svg tag receive events?

Kevin,

The original post is always available in the archives.

> Why the svg element should NEVER "dispatch" an event due to user
> interaction:

You cite parts of the svg spec as sustaining evidence. The validity itself
of the spec in regard to pointer events is in cause. The spec cannot be used
as evidence for argumentation. Essentially you say "The spec is right
because it says so", where we are contesting the very legitimacy of what it
says, as well as the self-attribution of the prerogative of overriding other
specifications. I trust you will make the necessary effort to understand
this.

Domenico



----- Original Message ----- 
From: "Kevin Ar18" <kevinar18@hotmail.com>
To: <nst@dotuscomus.com>; <www-svg@w3.org>
Sent: Wednesday, August 25, 2010 1:33 AM
Subject: RE: Should the base svg tag receive events?



I lost your original email, so I gotta reply to this one.  Let me see if I 
can clarify things:


Why the svg element should NEVER "dispatch" an event due to user 
interaction:
-----Pointer-events only affect [SVG Graphics 
Elements](http://www.w3.org/TR/SVG11/intro.html#TermGraphicsElement).  Other 
SVG elements do not visibly render on-screen; as such, pointer-events and 
user interaction has no meaning for non-graphical elements.  You may add the 
pointer-events property to certain non-graphical elements (like [SVG 
Container 
Elements](http://www.w3.org/TR/SVG11/intro.html#TermContainerElement)) for 
the purposes of inheritance; however, the propery has no other effect on 
non-graphical elements.
-----In terms of [DOM Level 2 
Events](http://www.w3.org/TR/DOM-Level-2-Events/), this means that when 
using a pointer device, elements that are not part of the [SVG Graphics 
Elements](http://www.w3.org/TR/SVG11/intro.html#TermGraphicsElement) can 
never "dispatch" an Event -- and they can never the the "target" of an 
event.  (Note that this does not prevent the use of 
[dispatchEvent](http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Registration-interfaces) 
to generate an "artificial" Event; the SVG spec only dictates how Events 
inititated by a pointer device are to be handled.)
-----The rationale for all of this is that non-graphical elements do not 
visibly appear on-screen; and, as such, there is nothing for the user to 
visually interact with.
-----Additionally, conforming implentations should not treat non-graphical 
SVG elements (such as the [SVG 
Element](http://www.w3.org/TR/SVG11/struct.html#SVGElement)) like an 
invisible layer that can "dispatch" events and block/intercept interaction 
with items underneath.


------
In your email, you mentioned:
> > Could there be slight confusion for some between event registration and
> > event dispatching, propagation and handling?

Yes, there probably is... and that's another good perspective.  So, let me 
explain it from that perspective as well:

Here's my definitions (which may or may not be what you mean):

-event registration = adding onclick (or a similar event) or using 
element.addEventListener to add an event listener to an element.  The SVG 
spec does not mess with this in any way.  You can register an event for any 
element (graphical or non-graphical).
-event dispatching = a process described in DOM2 here: 
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow
-element that dispatches the event = the element that starts the event flow 
process; it "dispatches" the DOM Event; it is equal to the "target" in the 
Event object; it is the elememt that the capture phase moves towards and the 
element that the bubble phase moves away from.

SVG specifies which element may "dispatch" an event based on user 
interaction.  After that, the DOM event flow process takes over and works 
like normal.  [Also, SVG has no effect on the DOM function: dispatchEvent()]


----
For additional clarification, I have added an attachment that shows things 
visually.


> >>> Note that in Opera, Firefox, Chrome and Safari, pointer events
> >>> registered on an outmost svg container with no graphical elements
> >>> (strictly empty), do trigger the event handler(s). In ASV they don't.
> >>> It's interesting that both the currentTarget and the target properties
> >>> designate the svg element, whereas to be strict only the currentTarget
> >>> should
> >>
> >> Well, what would you expect the target to be in that case?
An empty svg element should not trigger an event.  In this case, the target 
should be the element visually underneath the svg element (see attachment).



Of course others are planning to update the spec to clarify many of these 
issues... so it's possible something could change here.

Received on Wednesday, 25 August 2010 10:37:22 UTC