Re: Specifying hit testing in CSS

Yesterday at the F2F we discussed specifying default behavior for hit  
testing. Tantek is going to add it to CSS3 UI as an at-risk feature (since  
the key goal here is to standardize default behavior, not to get the  
property in at any cost). I was asked to specify our current behavior in  
greater detail as an action item.

I don't remember if doing it in terms of pointer-events was specifically  
mentioned, but that seems natural. I will build on Hixie's analysis from a  
few years back [1]. It describes IE's behavior, which is what we generally  
emulate.

First, however, to correct a slight inaccuracy:

http://krijnhoetmer.nl/irc-logs/css/20100824:
# [10:48] <Bert> Leif: Opera/IE  close to SVG's 'painted' value,
Gecko/Webkit close to 'visible'
# [10:49] <Bert> David: IE/Opera isn't really like 'painted'. They
actually look at the shape of the painted text.

This was probably mis-quoted, I believe David Baron was referring to SVG
looking at the shape of the painted text. Opera and IE certainly
do not hit test text paths in HTML.

However, I do believe that the characterization of SVG's behavior is
inaccurate too, as the spec refers to hit testing on a character-cell
basis [2] and several implementations (Opera, IE, Chrome, Firefox) agree  
[3]. So in SVG, hit testing deals with rectangular borders too (though  
admittedly at a a lower level, the character cell).

Now, to compare the Trident/Presto behavior to 'pointer-events: painted'.
Ignoring Hixie's items 2 (defined in Backgrounds & Borders), 1c, 4, and 5
(proprietary attributes), the following is relevant:

On Tue, 10 Feb 2009 01:18:45 +0000 (UTC), Hixie analyzed and found:

> IE considers a point of an element "transparent" if any
> one of the following are true:
>
>  1. All of the following are true:
>    a: The computed value of 'background-image' is 'none', and
>    b: The computed value of 'background-color' is 'transparent', and
(1c, 2)
> 3. The computed value of 'visibility' is 'hidden';
(4, 5)

Additionally, I find:

6. Both of the following is true:
   a: 'position' is 'static';
   b: There is no content.

Probably not too relevant. In any case, I expect the IE team to have a  
more precise and nuanced understanding of its behavior.

Opera deviates from this on certain points, but we consider those
differences to be insignificant or irrelevant for the spec. [4]

1 and 3 together seems to correspond pretty closely to 'visiblePainted',  
although borders are not considered. (This is interpreting 'fill' as  
background and 'stroke' as border.) Would it be possible for IE to switch  
to behaving like visiblePainted exactly (i. e. drop 6 and any other  
behaviors)? In that case, that behavior is a candidate for 'auto'.

I hope the IE guys as well as Gecko and WebKit will be able to examine the  
issue and see whether it's possible to switch to a unified behavior. As  
Anne mentioned yesterday at the meeting, this is an especially an issue  
for Korean and Chinese sites (where IE is dominant).

[1] Hixie's analysis:  
http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
[2] The pointer-events property in SVG:  
http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty
[3] Demo that illustrates SVG hit testing:  
http://people.opera.com/lstorset/demos/pointer-events/hit-testing.svg
[4] We hit transparent elements with event handlers - but making behavior  
depend on Ecmascript is mostly irrelevant for CSS. Static content is  
considered transparent, but it's not a very interesting behavior to  
mandate.

-- 
Leif Arne Storset
Core Technology Developer, Opera Software
Oslo, Norway

Received on Wednesday, 25 August 2010 14:37:08 UTC