W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: [cssom-view][css-ui] elementsFromPoint() and pointer-events:paint-order

From: Simon Pieters <simonp@opera.com>
Date: Tue, 25 Jun 2013 13:04:55 +0200
To: "Alan Stearns" <stearns@adobe.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "W3C WWW Style" <www-style@w3.org>, "glenn.adams@cox.com" <glenn.adams@cox.com>, "Ian Hickson" <ian@hixie.ch>, "Elliott Sprehn" <esprehn@gmail.com>, "Simon Fraser" <smfr@me.com>
Message-ID: <op.wy8eehfaidj3kv@simons-macbook-pro.local>
On Mon, 24 Jun 2013 17:58:39 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  

> On Mon, Jun 24, 2013 at 7:50 AM, Alan Stearns <stearns@adobe.com> wrote:
>> On 6/24/13 4:29 AM, "Simon Pieters" <simonp@opera.com> wrote:
>> Fair enough. But then I'd add a note to parallel the note above,  
>> something
>> like:
>> ---
>> The elementsFromPoint() method will return all painted elements at the
>> coordinates, even those excluded from being a target for hit testing by
>> using the 'pointer-events' CSS property.
>> ---
> Is that an intentional difference?  It seems weird for
> elementFromPoint and elementsFromPoint to use different methods to
> determine what's returned; in particular, it seems weird that if the
> top-most element has pointer-events:none, it'll be skipped by the
> former and returned as the first result by the latter.

Yes, it was intentional. See  

On Mon, 24 Jun 2013 18:53:09 +0200, Elliott Sprehn <esprehn@gmail.com>  

> Yeah, I'd hope they would behave identically except that
> elementsFromPoint() would return all the elements as if I had shot a line
> through the page along the z-axis.

On Mon, 24 Jun 2013 19:10:08 +0200, Alan Stearns <stearns@adobe.com> wrote:

> That was my preference as well, but reading through the bug discussion  
> [1]
> I see that it was proposed to include pointer-events:none elements  
> because
> (1) that's what IE's implementation currently does, (2) this method is  
> not
> intrinsically about hit testing and (3) you can filter  
> pointer-events:none
> elements out of the sequence if you like.
> I find (3) somewhat convincing - your code can ignore those elements if
> you like, but the elements are provided if you have a need for them. But  
> I
> would be happy with either including or excluding pointer-events:none
> elements in the sequence.

On Mon, 24 Jun 2013 20:24:43 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  

> Personally, I don't find these convincing enough arguments to justify
> the difference in behavior from elementFromPoint().  This will result
> in *much* confusion and gnashing of teeth if it stands.

OK, I excluded pointer-events:none from elementsFromPoint.


On Mon, 24 Jun 2013 21:10:46 +0200, Elliott Sprehn <esprehn@gmail.com>  

> Can we instead add an extra argument for this new magical behavior?
> Element elementFromPoint(x, y, includePointerEventsNoneStuff);
> sequence<Element> elementsFromPoint(x, y, includePointerEventsNoneStuff);

Use case?

> I feel like I should be able to do:
> ASSERT( elementFromPoint(x,y) == elementsFromPoint(x, y)[0]);
> Not having that definitely violates the principle of least wtfery :)

Simon Pieters
Opera Software
Received on Tuesday, 25 June 2013 11:03:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:31 UTC