[whatwg] Non-blocking SVG Canvas?

[Kevin Ar18]

> > First off, where would be an appropriate area to continue this conversation?
>
> Here is probably fine, unless you want one of www-style at w3.org or
> www-svg at w3.org.
>
> > I'm guessing the discussion is becoming less relevant to the HTML5 spec...
>
> But this isn't an HTML5 spec list... It's a whatwg spec list (which
> includes a lot more than HTML5).

Thank you for that.  I was a little bit unsure of myself... whether I should discuss this here or not.  If there's no issues, I guess I can continue here. :)
 
> > * Why do browsers do this? Is there somewhere in the specs that says empty (the transparent areas of) svg tags embedded inside another svg tag should "act like they do not exist"?
>
> One could interpret section 16.4 of the SVG 1.1 specification as saying
> this, maybe. I'm not sure whether any UAs actually implement that (in
> particular dropping on the floor events with no graphic element under
> them in SVG documents). Webkit and Opera certainly trigger the event
> handler for a click anywhere in the viewport given this SVG document:
 
Interesting point.
 
I've poured through several pages of the SVG spec to see if there was anywhere that would give some insight on what to do.  See if I'm reasoning this out correctly.
 
 
The SVG spec takes special effort to differentiate between the base SVG tag and nested SVG tags.  You can have an SVG document that has a proper mime type and the topmost element is the svg tag.  This has special clipping rules.  On the other hand if you have an SVGFragment that is part of a greater xml, html, etc... document that is in another namespace, then there is special negotiation rules for clipping.
 
The point is that the SVG spec takes some effort to differentiate between how SVG documents and and embedded SVG is handled in terms of clipping....
However, I find no such clarity when it comes to events.
 
 
------
events
------
16.4
"For each pointer event, the SVG user agent determines the target element of a given pointer event. The target element is the topmost graphics element whose relevant graphical content is under the pointer at the time of the event."
 
"target element is .. topmost graphics element"
graphics element = 
"One of the element types that can cause graphics to be drawn onto the target canvas. Specifically: ‘circle’, ‘ellipse’, ‘image’, ‘line’, ‘path’, ‘polygon’, ‘polyline’, ‘rect’, ‘text’ and ‘use’." (http://www.w3.org/TR/SVG11/intro.html#TermGraphicsElement)
 
Based on this, it would almost seem like svg events should not trigger on the base svg tag (when it is transparent), because there is no graphics element to receive the event.  Of course, we know that the browsers do not do this.
At this point, my question would be was this done not because it was in the spec, but because it seemed reasonable? ... Or is the problem that we are both misunderstanding the SVG spec?
 
-----------------------------------------------
No special mention of svg & non-svg interaction for events
-----------------------------------------------
Once again, going back to 16.4, it continues with:
"(See property ‘pointer-events’ for a description of how to determine whether an element's relevant graphical content is under the pointer, and thus in which circumstances that graphic element can be the target element for a pointer event.)"
 
Unlike when the spec deals with clipping, there is never a specific area that talks about how events between a non-svg namespace and the svg namespace should react.
 
 
-----------
my opinion?
-----------
Based on the limited info, it almost seems like the spec says that events should NOT trigger for the base svg tag (if it has no graphical content).  Even if it is a .svg file, the event should just "fall through" as you called it.  This is of course, not how browsers do it.
 
However, ignoring browsers for a second... if this is really what the specs suggest then the logical conclusion for HTML (with an svg tag in it) would be that events should drop through the transparent base svg to the underlying HTML 5 content/document.
 
 
I think I would really like to get some input from people who have done some work on the SVG spec. :)
 
 
Kevin