Working towards a clear understanding of the interaction between svg and html5.

If you are ok, with attachments, I've include an easier to read rtf version.
 

Working towards a clear understanding of the interaction between svg and html5.

This consists of 5 sections....  I realize that this is very long, but it is a very detailed issue.  The heart of the discussion is mostly in parts 4&5.

1. Rationale - Why this is an important issue:
The possibility to combine SVG graphics with HTML webpages presents some rather 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.
* 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.
Currently, none of this is possible with images, the box model, etc... because they all create an blocking square layer that bocks access to the content underneath.  SVG presents the opportunity to creat any type of odd shaped graphics that only blocks the content underneath in exactly the area that person specifies (no invisible blocking square boxes 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 (as more than just an image format, but as a way to graphically enchange pages).
2. Problem - The spec & Implemenations
After discussing this issue for sometime now, it still appears that there maybe too much vagueness (and maybe even some inconsitencies) in the specs.  The result is that different browser have a different understanding of this key html-svg interaction discussed above.  The result is various quirks and differences in each browser -- and, so far, not a very clear understanding of the way things really should be done.
3. My ultimate goal: consitency in all browser & (if possible) clarity in the spec
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.  Thus, there is some urgency for me, personally, to see this issue resolved quickly.
Once I was sure of thing from the spec side, it was my intention to write some testcases and make sure all the browser could be brought up to par with each other in this important area (preferably before the release of IE9, so IE9 worked the same as all the others).
4. Clarifying the SVG & HTML5 spec
I had been my hope that I would learn enough about this issue, the spec, the implementations, etc... but I guess that is not the case.  Instead, present an early draft based on my limited understanding (and potential flaws in the spec).  WARNING: You will find the HTML5 section woefully inadequate and/or wrong, as there are many problems that still need some discussion.  However, as far as I know, most of the SVG section is very close to the spec and "might" help clarify things.
SVG
> Insert into section 16.6, right before highlighted word: "pointer-events"
Additional clarification:
 Pointer-events only affect [SVG Graphics Elements](http://www.w3.org/TR/SVG11/intro.html#TermGraphicsElement).  All 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 use a pointer device, that 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 Event 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.
Context Menus:
 Occassionally, user agents choose to violate the spec in order to cater to the needs of the users.  As it relates to the SVG Spec, conforming user agents should resist the urge to treat the target for context menus differently than other type of DOM Events.  For example, adding pointer-events=none to a rect will cause all pointer events to fall through to the graphical element underneath.  In such a case, the target of the context menu should be the element underneath, even if the user cannot visually see it.
 Implementation suggestion: Conforming user agents must properly target the correct element (even if it is hidden) for context menus.  However, user agents may wish to offer additional context menu options for the visible item (in addition to the proper target); if and how user agents decide to implement such a feature is entirely up to their own discretion (and is not defined in this spec).

HTML5
> insert at the end of section 4.8.16
DOM Tree:
While, the svg element is within a separate namespace (the SVG namespace), the svg element and all its children are considered a part of the overall HTML5 DOM Tree that they are embedded in.  This means that the HTML5 document and the SVG text are part of a single parse tree, styles defined anywhere in the document apply to both namespaces, and event capture and bubbling flow back and forth between both namespaces (event capture and bubbling does not stop at the topmost svg element, for example).  Reference: [SVG 6.15 - Stand-along SVG content textually included in an XML document](http://www.w3.org/TR/SVG11/styling.html#Scope)
Interaction:
 The topmost svg element inserted into an HTML5 document must not "dispatch" Events (must not be the "target" of an user initiated Event) or block interaction with items visually underneath it.
 Rationale: The SVG specification states that non-graphical items (like the svg element) cannot "dispatch" Events (cannot be the "target" of an Event).  The svg element does not visibly appear on-screen; as such, there is nothing for the user to interact with or to receive events.
 Additionally, conforming user agents should also not create an invisible layer for the svg element, that can "dispatch" events or block interaction with items underneath.  Interaction with an empty svg element, for example, should fall through to items underneath.  This applies to registered EventListeners as well as user interaction, such as context menus, text selection, interaction with input and other elements.
 
5. Problems with HTML5 + SVG interaction and the HTML5 spec regarding the svg element.

Problem 1: You can't embed the svg element into html and have the svg element remain "pure" SVG anymore (as defined by the SVG specs).
 As I attempted to clarify in section 4, the SVG spec clearly treats the svg element as non-graphical and unable to "dispatch" pointer-events under ANY circumstance.  Contrast this with embedding an svg element into html5.  Now, you have additional styles that can be applied (that are not part of the SVG spec).  To fit into the flow of other html content, the containing svg element has to take on certain box model properties like position & display.  However, as a box model object, it seems nature that other properties also apply like border & background.
 This weird hybrid creates a very strange problem (and significant confusion).  Remember, svg elements are supposed to be non-graphical and are not supposed to trigger events because they have no graphics.  However, adding borders and backgrounds suddenly turns the non-graphical svg element into something that has no meaning in the SVG spec.  At this point, there is nowhere that can explain how an svg element with a background or border should handle events or whether it should block the user from interacting with content undereath it.
 At this point, different browsers do wildy different things when embedding an svg element in html5.  Use <svg position:absolute> and Firefox adds an invisible blocking layer so that you cannot interact with items underneath; in addition, Firefox will trigger events on this invisible svg element (in violation of the SVG spec).  On the other hand, consider Opera, which if you use <svg position:absolute> has the nice ability that it will not trigger events and does not create an invisible blocking layer so you can't access items underneath.  However, switch to a regular <svg> tag that is not absolutely positioned, and suddenly, the event will trigger on the invisible svg element (again in violation of the SVG spec).
 The problem stems from the fact that the HTML5 spec declares that the svg element is in the SVG Namespace, yet browsers constantly treat it like it is in the html namespace by supporting style properties that make no sense for an svg element (according to the SVG spec).  As of right now, I get a strong impression that the HTML5 spec for the SVG element needs a rewrite to clarify many issues, such as:
* the svg element should not be allowed to dispatch events or block the content underneath; this is VERY important to the integration of html + SVG and must be a part of the spec if SVG is to be useful as more than just an image format.
* What does it mean to say that the svg element is in the SVG Namespace (yet at the same time allowing css styles that are prohibited in the SVG spec?)
* What happens when you add a border or background?  Does the svg element become some other weird hybrid that can now block interaction with items underneath and trigger events or does it take on the pointer-events=none property and drop the event through the background to items underneath?
* Should position:absolute vs position:relative react differently (one can trigger events, one can't) -- currently Opera is treating them different?
* What about other css style properties or future ones that may affect the svg element in ways different than the SVG spec?
 
 
 
 
 
---------------------
I know this issue is very lengthy... and that really is a bad thing in that lots of people are going to get lost trying to wade through everything I wrote.  Still, I guess it's only fair to do it this way.  If you actually took the time to read... and actually understand where I'm coming from, then thank you so much.  Maybe you can help me to come to a clearer understanding of this issue; or, if necessary, clarify the spec.
 
Kevin