Useful background info
Some basic background info:
- The issue is regarding the topmost svg tag, when included in an html document.
This issue is not about object, embed, image, or any other html tags.
- The svg tag is mentioned in html5 here: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#svg-0
According to that, the svg element is within the svg namespace.
- The svg tag is consider non-graphical as noted by the list of graphical items in the SVG 1.1 spec.
- Non-graphical items render nothing on-screen -- meaning they can not be interacted with by the user, much less, trigger an event.
- As further proof, note how the svg spec defines that only graphics elements can be affected by pointer-events in Section 16.6.
This seems to reinforce the notion that the svg tag (a non-graphical element) should not be able to be interacted with or trigger events.
- As even further proof, consider the fact that an svg tag inside another svg tag will not trigger events. So why should the topmost svg tag be treated differently?
According to the current SVG spec, the base/topmost svg tag should not act differently.
In summary, when placing an svg tag in html, the correct behavior is to NOT block access to content underneath and to NOT trigger an event under any circumstance.
Clarification of the spec
The following is an attempt to clarify what the current SVG spec says.
Why the svg element should NEVER "dispatch" an event due to user interaction:
Pointer-events only affect [SVG Graphics Elements]. 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]) for the purposes of inheritance; however, the propery has no other effect on non-graphical elements.
In terms of [DOM Level 2 Events], this means that when using a pointer device, elements that are not part of the [SVG Graphics Elements] can never "dispatch" an Event -- and they can never be the "target" of an event. (Note that this does not prevent the use of the [dispatchEvent] function 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]) like an invisible layer that can "dispatch" events and block/intercept interaction with items underneath.
Problems, Conflicts, and Items that are unclear
At first glance is may seem like the SVG spec is clear enough to suggest proper behavior in browsers. However, several issues complicate the spec:
- Most, if not all, browsers support the ability to style the base svg element (in an HTML page) with CSS properties (like "border" and "background-color"). This seems natural to many people. However, it creates a conflict with the SVG spec. Suddenly, the non-graphcial svg element takes on graphical properties (like backgrounds) and there is no defined behavior for what to do in this case.
- In the future, SVG may introduce the ability to style the svg element with a background; this would also confuse the entire argument about non-graphical vs graphical elements.