- From: L. David Baron <dbaron@dbaron.org>
- Date: Fri, 18 Jul 2008 13:59:45 -0700
- To: Dean Jackson <dino@apple.com>
- Cc: www-style@w3.org
On Saturday 2008-07-19 06:17 +1000, Dean Jackson wrote: > 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> We'd been looking into implementing this property for all elements as well: https://bugzilla.mozilla.org/show_bug.cgi?id=380573 . If we want the property to have the same name as the SVG property, it needs to take the same set of values for all elements, since we can't tell at parse time whether a selector matches an SVG element or not. However, we could add values to the existing property (including values that are synonyms for each other) so that we can re-use the existing property. For example, we could add a value called 'border' that is a synonym for 'stroke', and say that: * when applied to SVG elements, either value means that the stroke is visible * when applied to non-SVG elements, either value means that the border is visible We also need to make sure that the default value for the property is compatible with the current default behavior in SVG and the current default behavior in non-SVG. (That may require a magical 'auto' value that, like the above, effectively means different things for SVG and non-SVG.) There's a bit of latitude here in cases where existing non-SVG implementations differ. (For example, my memory is that 'visibility: hidden' making elements not sensitive to events is pretty portable across browsers, though I could be wrong. But I think there are some other things that may vary.) > 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. I'm not sure what you mean by "text boxes" here. > Value: all | none | content | border | painted | inherit I'm not sure I like some of the names here, particularly 'content'. But I'm not sure if 'background' or 'box' would be any better. I'd also note that this property could also be designed to meet the feature request of having a way to make images sensitive to events only in the parts where they are non-transparent. > 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. Since this operates on the computed values of 'color', it should probably specify whenever the color has an alpha component of zero (since http://www.w3.org/TR/css3-color/#foreground and http://www.w3.org/TR/css3-color/#transparent define the computed value of 'transparent' to be rgba(0, 0, 0, 0)). > 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. If we want to use the same property name, I think we're stuck with keeping the values that SVG has. However, we can make an 'auto' value that defaults to different things as I proposed in https://bugzilla.mozilla.org/show_bug.cgi?id=380573 . > * 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'. One possibility here is to reuse the SVG property, and add value aliases as I described above so that all the SVG values that have "stroke" in the name can also be specified with "border" in the name, etc. > Because it's similar-but-not equivalent to SVG pointer-events, perhaps > it > should have a different name? As I said above, it should only have the same name if it accepts the same values, but adding values is OK. > 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. I could imagine wanting separate values to describe how images and text are hit-tested. We might even want to end up with a property that takes multiple values. So this could get complicated pretty quickly... > 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. I don't think the cost would be a significant increase relative to what we already have to do (except in the hopefully rare case of having lots of transparent images stacked on top of each other). > How does 'painted' interact with the opacity property? In WebKit, at > least, > elements with opacity: 0 still hit test. No strong opinion here, but it should be defined. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Received on Friday, 18 July 2008 21:00:22 UTC