Re: Should the base svg tag receive events?

Hi, Kevin-

Kevin Ar18 wrote (on 8/11/10 1:11 PM):
>
> The question is regarding the handling of events for the base svg
> tag.
>
> Details: As best I can understand the SVG specs, only graphical
> elements can receive event triggers (thus g, svg, etc... cannot
> trigger an event). However, if I setup a stand-alone svg file or if I
> add an svg tag to an html file, then the base svg element often
> triggers an event.
>
> Note: actual results varies in each browser for html pages. Based on
> the limited info in the specs (which says events only affect
> graphical elements), it would seem like the event should not trigger
> on the base/top-most svg tag.
>
> Am I understanding the specs correctly (and the browsers are doing it
> wrong) or is there more to it?

You are correct, <svg> elements are not rendering elements, neither as 
the root, nor nested within SVG or HTML roots.  Only rendering children 
of an <svg> element (not the <svg> element itself) are sensitive to 
pointer events.

The SVG root should not receive any mouse events if none of its 
graphical children has received the event.  Any implementation which 
does treat the SVG element as if it can receive pointer events is 
non-conforming.  Note that Opera, at least, does seem to exhibit the 
correct behavior.

This is kind of an understandable mistake.  HTML (as far as I know) 
never stated before that the HTML "background" was subject to pointer 
events, but that's the typical practice (and I expect that HTML5 
codifies that).  So, in light of that, SVG should have been explicit 
that it differs in this respect, so that implementers wouldn't get confused.

However, if you are looking for guidance in the SVG spec, it is stated 
fairly plainly.  SVG is defined as a "container element" and a 
"structural element", not as a "graphical element".  The section on 
interaction and pointer events states [1]:

[[
For each pointer event, the SVG user agent determines the target element 
of a given pointer event. The target element is the topmost graphics 
element whose relevant graphical content is under the pointer at the 
time of the event.
]]

So, <svg> elements are implicitly excluded from the category of normal 
pointer-event-sensitive elements.  Even more explicitly, in the section 
on processing order for user interface events, it lists the order and 
manner in which events get processed, from graphical elements and 
preventDefault(),, to CSS pseudo-classes, to any default actions they 
may have (such as for links), to text selection, ending in the following:
[[
Document-wide event processing, such as user agent facilities to allow 
zooming and panning of an SVG document fragment.
]]

In other words, evoking the context menu (or otherwise exposing UA 
controls) is the only thing that an <svg> element is sensitive to, not 
typical DOM events.

This is clearly the normal desired behavior, though I can see use cases 
for making the <svg> element respond to pointer events (such as for 
drag-n-drop).  But especially when used with HTML, the SVG should pass 
events through to any underlying HTML content for the "background" of 
the SVG fragment.  Otherwise, it's little better than black-box plugins 
in this respect.

Boris pointed out a hack, setting pointer-events to 'none' for the <svg> 
root element and to 'inline' for any child elements you want to respond 
to the pointer; this is an unfortunate but reasonable workaround for 
now, until they get this fixed.

(There is a bug in WebKit that is somewhat conceptually related [3], 
which renders a white, non-transparent background for SVG fragments or 
documents; I don't know if they are related programatically, but I wish 
both bugs would be resolved.)


We will spell this out more explicitly in SVG 2.  In the meantime, the 
sections I cite above should be sufficient justification for fixing this 
bug in any browsers with this bug.  It's possible we could even clarify 
this in SVG 1.1 2nd Edition, if that would help.


All that said, I think SVG 2 should consider the various use cases 
around this and come up with clear, consistent, and simple rules for 
pointer events in different scenarios, so that it is more intuitive to 
people coming from the HTML+CSS world.  (Similarly, I think the SVG 
root, and maybe container elements in general, should honor certain CSS 
properties such as the background property.)


[1] http://www.w3.org/TR/SVG/interact.html#PointerEvents
[2] http://www.w3.org/TR/SVG/interact.html#UIEventProcessing
[3] 
https://lists.webkit.org/pipermail/webkit-unassigned/2009-July/120301.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Friday, 13 August 2010 05:07:54 UTC