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

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

From: Elliott Sprehn <esprehn@gmail.com>
Date: Mon, 24 Jun 2013 12:10:46 -0700
Message-ID: <CAPJYB1hh0NZkdoz_NOPe0c7GPKRi21P-s5mNgOXzrxz-qo6qBA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Alan Stearns <stearns@adobe.com>, Simon Pieters <simonp@opera.com>, W3C WWW Style <www-style@w3.org>, "glenn.adams@cox.com" <glenn.adams@cox.com>, Ian Hickson <ian@hixie.ch>, Simon Fraser <smfr@me.com>
On Mon, Jun 24, 2013 at 11:24 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Mon, Jun 24, 2013 at 10:10 AM, 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.
>
> 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.
>

Can we instead add an extra argument for this new magical behavior?

Element elementFromPoint(x, y, includePointerEventsNoneStuff);
sequence<Element> elementsFromPoint(x, y, includePointerEventsNoneStuff);

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 :)

- E
Received on Monday, 24 June 2013 19:11:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC