- From: Doug Schepers <schepers@w3.org>
- Date: Fri, 13 Aug 2010 01:07:50 -0400
- To: Kevin Ar18 <kevinar18@hotmail.com>
- CC: www-svg@w3.org
Hi, Kevin- Kevin Ar18 wrote (on 8/11/10 1:11 PM): > > The question is regarding the handling of events for the base svg > tag. > > Details: As best I can understand the SVG specs, only graphical > elements can receive event triggers (thus g, svg, etc... cannot > trigger an event). However, if I setup a stand-alone svg file or if I > add an svg tag to an html file, then the base svg element often > triggers an event. > > Note: actual results varies in each browser for html pages. Based on > the limited info in the specs (which says events only affect > graphical elements), it would seem like the event should not trigger > on the base/top-most svg tag. > > Am I understanding the specs correctly (and the browsers are doing it > wrong) or is there more to it? You are correct, <svg> elements are not rendering elements, neither as the root, nor nested within SVG or HTML roots. Only rendering children of an <svg> element (not the <svg> element itself) are sensitive to pointer events. The SVG root should not receive any mouse events if none of its graphical children has received the event. Any implementation which does treat the SVG element as if it can receive pointer events is non-conforming. Note that Opera, at least, does seem to exhibit the correct behavior. This is kind of an understandable mistake. HTML (as far as I know) never stated before that the HTML "background" was subject to pointer events, but that's the typical practice (and I expect that HTML5 codifies that). So, in light of that, SVG should have been explicit that it differs in this respect, so that implementers wouldn't get confused. However, if you are looking for guidance in the SVG spec, it is stated fairly plainly. SVG is defined as a "container element" and a "structural element", not as a "graphical element". The section on interaction and pointer events states [1]: [[ 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. ]] So, <svg> elements are implicitly excluded from the category of normal pointer-event-sensitive elements. Even more explicitly, in the section on processing order for user interface events, it lists the order and manner in which events get processed, from graphical elements and preventDefault(),, to CSS pseudo-classes, to any default actions they may have (such as for links), to text selection, ending in the following: [[ Document-wide event processing, such as user agent facilities to allow zooming and panning of an SVG document fragment. ]] In other words, evoking the context menu (or otherwise exposing UA controls) is the only thing that an <svg> element is sensitive to, not typical DOM events. This is clearly the normal desired behavior, though I can see use cases for making the <svg> element respond to pointer events (such as for drag-n-drop). But especially when used with HTML, the SVG should pass events through to any underlying HTML content for the "background" of the SVG fragment. Otherwise, it's little better than black-box plugins in this respect. Boris pointed out a hack, setting pointer-events to 'none' for the <svg> root element and to 'inline' for any child elements you want to respond to the pointer; this is an unfortunate but reasonable workaround for now, until they get this fixed. (There is a bug in WebKit that is somewhat conceptually related [3], which renders a white, non-transparent background for SVG fragments or documents; I don't know if they are related programatically, but I wish both bugs would be resolved.) We will spell this out more explicitly in SVG 2. In the meantime, the sections I cite above should be sufficient justification for fixing this bug in any browsers with this bug. It's possible we could even clarify this in SVG 1.1 2nd Edition, if that would help. All that said, I think SVG 2 should consider the various use cases around this and come up with clear, consistent, and simple rules for pointer events in different scenarios, so that it is more intuitive to people coming from the HTML+CSS world. (Similarly, I think the SVG root, and maybe container elements in general, should honor certain CSS properties such as the background property.) [1] http://www.w3.org/TR/SVG/interact.html#PointerEvents [2] http://www.w3.org/TR/SVG/interact.html#UIEventProcessing [3] https://lists.webkit.org/pipermail/webkit-unassigned/2009-July/120301.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Friday, 13 August 2010 05:07:54 UTC