W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Proposal for CSS 'pointer-events' property

From: Dean Jackson <dino@apple.com>
Date: Sat, 19 Jul 2008 06:17:22 +1000
Message-Id: <E096A2EE-8B0D-49FF-8C98-2284C4431DF2@apple.com>
To: www-style@w3.org

Hi all,

Here is a proposal for a new property we've been investigating (new to  
HTML,
at least). We'd appreciate any feedback from the community.

Proposal
--------

Positioning and CSS transforms allow authors to create content with  
elements
that overlap in many different ways. This flexibility in presentation,
however, has not been matched by improved control over event handling.  
Events
still propagate through the document via the DOM hierarchy, a model  
which made
sense when parent elements always visually enclosed their children,  
but now
becomes more problematic. For example, if an element is overlayed by  
another
element that is not a descendent, there is no way for that background  
element
to receive mouse events.

We propose a new CSS property for HTML, "pointer-events", to address  
this
problem. This property is closely modeled on the SVG pointer-events  
property:

<http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty>

Values for this property allow the content author to make elements  
entirely,
or partially transparent to user events. This would also apply to  
other "hit
testing" behaviors such as dynamic pseudo-classes  
(:hover, :active, :focus),
hyperlinks, and Document.elementFromPoint().

Note that no values of this property cause an element to be hit-tested  
when it
would not have been hit tested before. When hit-testing text, text  
boxes are
used, as is already the case.

Note that the pointer-events property is only consulted when  
determining the
target of an event. Once the target element has been identified, event
propagation follows the existing DOM model.

'pointer-events'
   Value:          all | none | content | border | painted | inherit
   Initial:        all
   Applies to:     all elements
   Inherited:      yes
   Media:          visual


all
   The given element can be the target element for pointer events
   whenever the pointer is over the contents, background, or border
   of the element. This is the current HTML behavior. Note that  
outlines,
   shadows and reflections do not hit test.

none
   The given element does not receive pointer events.

content
   The given element can be the target element for pointer events
   when the pointer is over the interior (i.e., content or background)
   of the element.

border
   The given element can be the target element for pointer events
   when the pointer is over the border of the element.

painted
   The given element can be the target element for pointer events
   when the pointer is over a "painted" area. The pointer is over a  
painted
   area if it is over the interior (i.e. content or background),
   or border of the element, and when the content, border or background
   does not have a 'transparent' color.


Issues
------

The property is very similar the SVG 'pointer-events' property, but  
differs
in the following ways:

    * We do not want the property to interact with 'visibility';  
visibility:
      hidden elements should not hit test. So we do not have the dual  
values
      (e.g. 'painted', 'visiblePainted') that SVG does.

    * SVG's 'fill' and 'stroke' values don't translate well to HTML's
      background, foreground, border model, so we propose just 'content'
      (background and foreground), and 'border'.

Because it's similar-but-not equivalent to SVG pointer-events, perhaps  
it
should have a different name?

Do we want separate values for foreground, background and border? SVGs  
fill
vs. stroke doesn't map cleanly to HTML. It doesn't seem to make much  
sense to
hit test background and not content, but you may want to include/exclude
border.

Should the implementation for 'painted' look at pixel alpha values?  
Doing so
would require examining pixels in content images, background images,  
border
image, background color, border color, text color, masks, CSS  
gradients etc.
This is both hard to implement, and could be very expensive at runtime  
(on
every mouse move), but is something that content authors may want.

How does 'painted' interact with the opacity property? In WebKit, at  
least,
elements with opacity: 0 still hit test.
Received on Friday, 18 July 2008 20:18:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:10 GMT