W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2011

Re: [CSS3-UI] Still uncertain how to handle pointer-events for the top svg tag.

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Tue, 18 Jan 2011 15:24:13 -0800
Message-ID: <AANLkTi=izd9cNaOswyrAk3aL8oyhw9Gba52mjqLv=NeR@mail.gmail.com>
To: Kevin Ar18 <kevinar18@hotmail.com>
Cc: public-fx@w3.org, www-style@w3.org, www-svg@w3.org, Doug Schepers <schepers@w3.org>
This is regarding issue 5 for CSS3-UI - please reference that issue #
and preferably this URI in any response/follow-up:


(URIs > email)

On Thu, Nov 18, 2010 at 17:12, Kevin Ar18 <kevinar18@hotmail.com> wrote:
> Summary of problem:
> There is still disagreement on whether the top svg tag in html/css should
> trigger pointer-events.
> CSS-SVG Task Force says it should not:
> http://dev.w3.org/csswg/css3-ui/#pointer-events

I'm assuming that link was supposed to be:

which doesn't provide much reasoning to go on.

> CSS3-UI says it should: http://wiki.csswg.org/spec/css3-ui#issue-5
> So, there are at least two opposing views on the correct way to handle this
> issue.  It is not my decision to say which way it should be done, but it
> would be nice to get the question settled by all parties... and have all
> browsers handle it the same way. :)

I'm not sure the views are that different, at least as far as the
desired outcome/effect is concerned.

And yes, interop is strongly desirable :)

> To help things along, I included the following bits of info.
> I. Why is this useful?
> II.  Any solution should meet several requirements (they are listed below).
> III. A summary of the 2 different views.
> I. Why is this useful?
> For anyone new to the discussion, the ability to integrated SVG and HTML,
> presents some interesting possibilities for future websites. Consider the
> following:
> Using SVG to circle text or html items on a wepage (but still allow those
> items to be interacted with).
> 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 parts of the page, yet still
> be able to interact with the html object(s) underneath.
> Creating a graphical object "under" the cursor that follows the mouse, but
> still lets you interact with items underneath it.
> You can view some examples of this here:
> http://lists.w3.org/Archives/Public/public-fx/2010JulSep/att-0084/Results.zip
> -- see index.html & example.xhtml in that file

Sounds reasonable.

> II. Any solution should probably meet these basic requirements:
> 1. There MUST be a way for the svg tag to not receive pointer-events, while
> still allowing all it's child nodes to continue receiving pointer-events.

@namespace svg "http://www.w3.org/2000/svg";
svg|svg { pointer-events: none }
svg|svg>* { pointer-events: visiblePainted }

(now included in the CSS3-UI editor's draft default style sheet)


(as of today, 2011-018)

> 2. There MUST be a way to force the svg tag to receive pointer-events within
> it's entire rectangular area (the area defined by width & height).

@namespace svg "http://www.w3.org/2000/svg";
svg|svg { pointer-events: all }

> 3. Address whether embed, img, svg, and any other forms of inserting svg
> should act differently for pointer-events.

embed { pointer-events: auto } /* modify as desired for embed elements */
img { pointer-events: auto } /* modify as desired for img elements */

/* for the 'svg' element, see above */

> 4. Make sure these can be implemented the same way all browsers.

Above solutions are implementable the same way across browsers.

I consider this issue tentatively resolved per the documented
resolution on the issues page (examples provided above of how it

If there are additional SVG-specific details (other odd details of
which SVG elements or classes of element do or do not take
pointer-events by default), please add to the issue:



editor, CSS3 UI

http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Received on Tuesday, 18 January 2011 23:26:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:37 UTC