(read first) Working towards a clear understanding of the interaction between svg and html5.

Apologies to everyone who actually waded through that other copy.  I have gone through it and fixed the wording to be a little more understandable.
 
I press myself for time... and just got so tired of spending hours on the issue, that I submitted the poor draft.
----------------------
 
 
 
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 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.
Currently, this is not really possible with images, the box model, etc... because they all create a blocking square, which bocks access to content underneath.  SVG presents an opportunity to create any shape graphics that only blocks the content underneath in exactly the areas that a person 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 (as more than just an image format, but as a way to graphically enhance pages).
2. Problem - The spec & Implemenations
After discussing this issue for a while, there still appears to be some vague areas (and maybe some inconsitencies) in the specs.  The result is that different browser have a different understanding of html-svg interaction.  Each browser has various quirks, bugs, and differences in implemenation; the implementers of the browsers also seem to disagree about the right way it should be done according to the "spec".
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.
It was my hope to gain a clear understanding of the spec, write some testcases, and make sure all browsers 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).  I still would like to aim for this goal; so I am continued to pursue this issue.

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, I present a draft of some clarifications to the SVG and HTML5 spec.  WARNING: You will find the HTML5 section woefully inadequate and/or wrong, as there are many problems that I still need to discuss.  However, as far as I know, most of the SVG section is very close to the spec and, just might actually 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).  Because other SVG elements do not render on-screen; user interaction (using a pointing device) has no meaning for these non-graphical elements.  You may still add the pointer-events property to some 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: 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.
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 DOM Events.  For example, adding pointer-events=none to a SVGRect 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 (not the visible SVGRect), even though the user cannot visually see the item underneath.
 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; if and how user agents decide to implement such a feature is at 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.  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 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).
 The SVG spec treats the svg element as non-graphical, which means it can't "dispatch" pointer-events under ANY circumstance.  Contrast this situation with embedding an svg element into html5.  When you do this, you now 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 takes on certain box model properties like position & display.  However, as a box model object, it seems natural that other properties also apply like border & background.
 This weird hybrid creates a problem (and significant confusion).  Remember, svg elements are supposed to be non-graphical and are not supposed to trigger events.  However, adding borders and backgrounds suddenly turns the non-graphical svg element into some weird graphical element that has no meaning in the SVG spec.  At this point, the svg element is in no-mans-land, where none of the specs accurately describes what should happen: how does an svg element with a background or border handle events?  Should it block the user from interacting with content undereath it?  The answer is no longer so clear.
 As of this writing, different browsers do wildy different things when adding a svg element into an html5 document.  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 (like the SVG spec states).  However, switch to a regular <svg> tag that is not absolutely positioned, and suddenly, the event will trigger on the invisible svg element (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 the svg element must also be treated like it is in the html namespace for various properties.  For example, the svg element supports style properties that make no sense for an svg element (according to the SVG spec).  Here are a few areas that could use some clarification (for me personally, or in the spec -- not sure which):
* 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 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?
* If the svg element (inside an HTML5 document) can take on css properties like border and background and can follow the CSS box model, then should it abandon certain SVG properties in order to conform to these html&css properties?
 
 
 
 
 
---------------------
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