[whatwg] Non-blocking SVG Canvas?
First off, let me start with a question to see if maybe I missed something somewhere: Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath? As far as I know, there is no way to do this using the HTML5 spec. However, if I am wrong, then there is no need for the rest of this discussion. Rationale: One of the greatest benefits I see in SVG is the way it can potentially be used to integrate with HTML pages and affect the visual layout in new ways. Unfortunately, the current SVG-HTML integration keeps the two quite separated. >From my perspective, there are two features that would make SVG drastically >more useful to websites: 1) The ability for SVG shapes to affect the flow and positioning of HTML elements (not just a square inserted into the the page, but the actual odd shape of SVG objects changing text borders, relative positioning of inline elements, etc... -- html currently has no such box/layout model like this). 2) The ability to overlay svg objects over certain parts of the page, but the transparent areas act like they don't exist. The first point is too complex to deal with now. However, the second point might be possible with minimal changes to the spec -- and, hopefully, minor changes to browsers. Proposal: 1. Add a new property to the tag, such as: blockingcanvas="true|false" (just an example) 2. When set to non-blocking mode... any transparent areas act like they do not exist. This particularly makes sense, when you overlay an SVG shape on top of other content on your website (usually HTML), then content in the transparent areas can be interacted with just like normal. Problem: 1. Needed to make SVG-HTML interaction more useful 2. This might need clarification in the specs because already different browsers treat the transparent part of the svg canvas differently. Opera has the ability to allow interaction with content beneath the transparent area (although it might be buggy). Firefox blocks the entire transparent svg canvas even if it contains no SVG objects. Example and further clarification: At the end of this message is a sample page. Anyways, in this example, the canvas hovers over the content of the page. * In my proposal, you should be able to click on all the google links that you can see (many are underneath the svg canvas). * As always, actual SVG objects (like the red line) would block interaction with (and visibility of) the material underneeth. * In terms of events, "click", "mouseout", "mouseover", etc... on the red line (SVG path) would trigger an event on the SVG path only). * In terms of events on the transparent area inside and outside the red line would trigger an event on the content underneath -- which in this case may be the document body or one of the links. * Standard browser interaction like text selection, context menus, etc... would also be affected. * Essentially, it would be treated like the transparent areas of the canvas do not exist and the content underneath is what is being interacted with. * Other issues: How "border" style affects the svg canvas blocking/non-blocking would need clarification. -- http://www.w3.org/1999/xhtml";> http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.google.com/";>google.com http://www.w3.org/2000/svg"; width="500" height="500">
Re: [whatwg] Non-blocking SVG Canvas?
On 8/5/10 3:14 PM, Kevin Ar18 wrote: Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath? Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty -Boris
Re: [whatwg] Non-blocking SVG Canvas?
> On 8/5/10 3:14 PM, Kevin Ar18 wrote: > > Is it possible to create an SVG shape (say a hollow circle) that allows you > > to click through the invisible areas of the svg canvas to html objects > > underneath? > > Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty Quick question, if you are familiar with it. This seems to only affect SVG objects interacting with other SVG objects (inside an SVG canvas). Does it also apply to the SVG canvas inside an HTML page?
Re: [whatwg] Non-blocking SVG Canvas?
On 8/5/10 3:36 PM, Kevin Ar18 wrote: On 8/5/10 3:14 PM, Kevin Ar18 wrote: Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath? Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty Quick question, if you are familiar with it. This seems to only affect SVG objects interacting with other SVG objects (inside an SVG canvas). Does it also apply to the SVG canvas inside an HTML page? This might depend on the browser, since nothing actually defines the interaction of SVG and HTML in this area very well. Per SVG spec, pointer-events is not supposed to apply to , for example. However in the case of Gecko specifically, the "none" value is supported for all elements, not just SVG elements. So if you set pointer-events:none on the and then whatever values of pointer-events you want on its descendants, things should work. In Opera and Webkit it looks like doesn't get events by default at all. So there's no issue. So this testcase does what you want, I think, in all of Opera, Webkit, Gecko. http://www.w3.org/1999/xhtml";> http://www.w3.org/2000/svg";> -Boris
Re: [whatwg] Non-blocking SVG Canvas?
> > Is it possible to create an SVG shape (say a hollow circle) that allows you > > to click through the invisible areas of the svg canvas to html objects > > underneath? > > Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty > > -Boris Another followup. First, I should thank you for that piece of info. I was indeed not aware of that particular property. I tried: pointer-events:painted ... and at the suggestion of a friend, I tried: pointer-events:none Results: Opera -- works Opera (no pointer-event style): * click through works fine (canvas non-blocking) -- links, and various mouse events work on the document HTML body Opera (pointer-events:painted): * same as above Firefox Gecko/20100804 Minefield/4.0b3pre -- very buggy (no pointer-event): * blocks everything underneath the invisible canvas (pointer-events:painted): * blocks everything underneath (poiner-events:none): * this seems to work uzbl git.20100403-2 * click through works (canvas non-blocking) So, would the conclusing (based on the specs and the results) be that Firefox is the problem here and I need to file some bug report(s)? ... or is there any vagueness in the spec that might be the cause?
Re: [whatwg] Non-blocking SVG Canvas?
> This might depend on the browser, since nothing actually defines the > interaction of SVG and HTML in this area very well. Per SVG spec, > pointer-events is not supposed to apply to , for example. > > However in the case of Gecko specifically, the "none" value is supported > for all elements, not just SVG elements. So if you set > pointer-events:none on the and then whatever values of > pointer-events you want on its descendants, things should work. > > In Opera and Webkit it looks like doesn't get events by default at > all. So there's no issue. So this testcase does what you want, I > think, in all of Opera, Webkit, Gecko. Seems we came to a similar conclusion (and similar test cases). :) Do you think there is a need for some clarification on this issue in the HTML5 specs?
Re: [whatwg] Non-blocking SVG Canvas?
On 8/5/10 4:16 PM, Kevin Ar18 wrote: Do you think there is a need for some clarification on this issue in the HTML5 specs? I think there's work on a clarification going on already in the CSS working group. See the thread starting with http://lists.w3.org/Archives/Public/www-style/2008Jul/0428.html -Boris
Re: [whatwg] Non-blocking SVG Canvas?
> > Do you think there is a need for some clarification on this issue in the > > HTML5 specs? > > I think there's work on a clarification going on already in the CSS > working group. See the thread starting with > http://lists.w3.org/Archives/Public/www-style/2008Jul/0428.html I guess that would solve future issues... but it involves a new spec right? My concern is that we get this specific HTML5-SVG interaction right now, so that SVG can be much more useful on regular websites in the very near future. Since the problem area is Firefox, I thought maybe I could file a bug report and take care of this issue that way. However, I am not clear on the specs and whether I should file a report. According to here (http://www.w3.org/TR/SVG11/struct.html#SVGElement) pointer-events is a property of the svg tag. According to here (http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty) pointer-events is not a property of the svg tag since svg is not part of the graphical elements group. In fact, this is what you said in another email. So, does this actually mean a browser should not support pointer-events for the svg tag within a html document? I was considering filing a report for Firefox about not supporting pointer-events:painted for the svg tag inside an html document. P.S. I know, I should probably switch to the implementations mailing list soon, but I just want to confirm a few things about the spec before I start doing testcases and bugreports. :)
Re: [whatwg] Non-blocking SVG Canvas?
On 8/5/10 4:40 PM, Kevin Ar18 wrote: I guess that would solve future issues... but it involves a new spec right? Well, any sort of clarification here does, yes. My concern is that we get this specific HTML5-SVG interaction right now It needs a new spec no matter what, no matter where it lives... Since the problem area is Firefox In the sense that in Gecko is not transparent to events by default? Note that transparency to events is not even interoperable inside HTML; e.g. an empty div will block events in some browsers but not others. That said, support for pointer-events:none on arbitrary elements makes this point moot; you just assume the worst and add styles that describe the exact behavior you want. However, I am not clear on the specs The specs do not define event targeting behavior at all. According to here (http://www.w3.org/TR/SVG11/struct.html#SVGElement) pointer-events is a property of the svg tag. Correct. According to here (http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty) pointer-events is not a property of the svg tag since svg is not part of the graphical elements group. Not quite. It doesn't _apply_ to the tag. But it's a property of all elements. And since it inherits by default, this distinction is a meaningful one (e.g. you can set pointer-events to some value on an to set it to that value on all graphical elements contained in the ). So, does this actually mean a browser should not support pointer-events for the svg tag within a html document? Technically, per SVG spec, yes. I believe there is common agreement (well, at least in Webkit and Gecko) that this needs a spec change to give better behavior. I was considering filing a report for Firefox about not supporting pointer-events:painted for the svg tag inside an html document. The thing is... as "painted" is defined in the SVG spec, it doesn't make sense for (which never has any fill or stroke that actually do anything). This is why a separate spec is needed to define the behavior here. That said, you may be interested in https://bugzilla.mozilla.org/show_bug.cgi?id=380573 -Boris
Re: [whatwg] Non-blocking SVG Canvas?
First off, where would be an appropriate area to continue this conversation? I'm guessing the discussion is becoming less relevant to the HTML5 spec... and I don't want to bother others on this list. (Sorry to everyone for any issues this causes.) Would this be better continued on the SVG mailing list, the whatwg implementation list, or via private email? > >>> Is it possible to create an SVG shape (say a hollow circle) that allows > >>> you to click through the invisible areas of the svg canvas to html > >>> objects underneath? > >> > >> Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty > > > > Quick question, if you are familiar with it. > > > > This seems to only affect SVG objects interacting with other SVG objects > > (inside an SVG canvas). > > > > Does it also apply to the SVG canvas inside an HTML page? > > This might depend on the browser, since nothing actually defines the > interaction of SVG and HTML in this area very well. Per SVG spec, > pointer-events is not supposed to apply to , for example. If I may pose another question: Consider the following: * Insert an svg tag inside another svg tag * Layer the svg tags on top of each other. * Put content inside each svg tag. * Notice how the layered svg tag is treated like it has the following default properties: pointer-events:painted visibility:visible My question is as follows: * 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"? The reason I ask, is because if this is defined in the spec somewhere, then that means an svg tag embedded in html should have the same properties (transparent areas should be click-through and/or pointer-events:painted should work). Here is an example: ---
Re: [whatwg] Non-blocking SVG Canvas?
On 8/5/10 9:14 PM, Kevin Ar18 wrote:
First off, where would be an appropriate area to continue this conversation?
Here is probably fine, unless you want one of www-st...@w3.org or
www-...@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).
* 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:
http://www.w3.org/2000/svg"; onclick="alert('clicked')"/>
-Boris
Re: [whatwg] Non-blocking SVG Canvas?
> > First off, where would be an appropriate area to continue this conversation? > > Here is probably fine, unless you want one of www-st...@w3.org or > www-...@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
Re: [whatwg] Non-blocking SVG Canvas?
On 8/6/10 9:16 PM, Kevin Ar18 wrote: I think I would really like to get some input from people who have done some work on the SVG spec. :) www-...@w3.org is the right place for that. -Boris
Re: [whatwg] Non-blocking SVG Canvas?
> > I think I would really like to get some input from people who have done > > some work on the SVG spec. :) > > www-...@w3.org is the right place for that. Thanks, I sent off a question there. However, back to HTML5 4.8.16 It says that the svg element is in the SVG namespace... however, it describes the element as being: "embedded content, phrasing content, and flow content categories for the purposes of the content models in this specification." Would describing svg under these 3 content models in any way imply that the svg tag should act like an invisible box to capture events (and block everything underneath). Essentially, if I were to find out that according to the SVG specs, the svg canvas should not block items underneath... then my question is does anything in the HTML5 spec say that it should block? ... or perhaps it could be interpreted either way?
