- From: Dean Jackson <dino@apple.com>
- Date: Sat, 19 Jul 2008 06:17:22 +1000
- 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 UTC