Rationale - Why this is an important issue.
The ability to integrated SVG and HTML, presents some interesting possibilities for future websites. Consider the following:
- Using SVG to circle text or html items on a wepage.
- Drawing arrows from one part of the page to the other (but not block content underneath).
- Having oddly shaped menus, borders, layers, etc....
- Adding a "hazy" or semi-tranparent layer over html object, yet still be able to interact with the html object underneath.
- Creating a graphical object "under" the cursor that follows the mouse, but still lets you click on items underneath it.
As far as I know, none of this is possible with any current HTML features. Images, the box model, etc... all create a blocking square, that bocks access to content underneath. In addition, the blocking area is always a rectangular shape. SVG presents an opportunity to create any shape graphics that can block the content underneath in only the areas that a page author specifies (no more invisible blocking square or even being limited to 100% transparent areas).
I would classify the html-svg interaction as very important to the future use of SVG+HTML. By integrating into pages in the manner described above, SVG could be used as more than just an image format; it could be used as a way to graphically enhance pages.
Example(s).
Here are a few examples of what you might be able to do with these kinds of features. (works in Firefox/Gecko and Opera; fails in Safari/Webkit)
Ultimate Goal regarding this issue.
HTML+SVG interaction is one of those core issue that you need to get right if people can use SVG in the ways I described earlier. This means all the browsers need to handle it correctly (whatever that means) as soon as possible, so that sites can take advantage of it as soon as feasable.
Useful 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 consider non-graphical as noted by the list of graphical items in the SVG 1.1 spec.
- Non-graphical items render nothing on-screen
- Non-graphical items can not be interacted with by the user, much less, trigger an event.
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.
Does CSS override the SVG intentions?
Consider what happens when you add the svg element to an html5 document. The CSS specs treat SVG as replaced content.
Implementers from Mozilla have argued that this means the topmost SVG element-in-html should act like an invisible blocking layer just like all other replaced content. Unfortunately, this issue is not clear in the CSS spec, but does raise an interesting question as to whether this is a CSS issue and not an SVG issue (in terms of which spec controls the behavior).