Re: Proposal for CSS 'pointer-events' property

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