Tests

  1. Visual Examples
    ^ These "Visual Examples" provide an easy to understand "visual" explanation.
    ^ These 4 examples are the basis for the automated and manual tests.
  2. Automated Pass/Fail Browser Tests
    ^ This is a test suite that will provide you with a pass/fail for various features ... and can be used to check how different browsers react.
    * The test also "prints out" the results in the textbox at the bottom, which can be used to study how the browser reacted to each test.
  3. Manual Browser Tests
    ^ This is another pass/fail test covering features that cannot be automated. They must be checked manually by a human.
    ^ Most of these manual tests are formal tests based on problem observed in the 2 demonstrations below.
  4. Working demonstrations.
    These 2 examples provide an informal way to check desired behavior ... and can be used to find issues in implementations.

Background Details

Rationale - Why this is an important issue.

The ability to integrated SVG and HTML, presents some interesting possibilities for future websites. Consider the following: 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

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).