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.