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

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

From: Alan Stearns <stearns@adobe.com>
Date: Wed, 19 Jun 2013 15:13:47 -0700
To: Alan Stearns <stearns@adobe.com>, W3C WWW Style <www-style@w3.org>
CC: "simonp@opera.com" <simonp@opera.com>
Message-ID: <CDE77AD0.2C711%stearns@adobe.com>
On 6/19/13 2:09 PM, "Alan Stearns" <stearns@adobe.com> wrote:

>On 6/13/13 3:22 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
>>On Thu, Jun 13, 2013 at 3:18 PM, Alan Stearns <stearns@adobe.com> wrote:
>>> We've discussed adding an elementsFromPoint() method in the recent past
>>> [1] and it's relevant to the topic I brought up in Tokyo last week
>>>about
>>> event handling in fragment containers.
>>>
>>> There are several related use-cases:
>>>
>>> 1. Connecting a fragment container with a user event [2]
>>> 2. Finding a not-topmost element under the cursor
>>> 3. Avoiding hover-at-a-distance for positioned children
>>>
>>> I suggest adding an elementsFromPoint() method to cssom-view that
>>>returns
>>> all the elements under a particular point sorted in paint order (top to
>>> bottom). People use various hacks for this today (removing topmost
>>> elements or setting pointer-events:none on them to reveal the elements
>>> underneath, then restoring the stack) that could be avoided by using
>>>this
>>> new method.
>>>
>>> Then I suggest adding a new value to the pointer-events property (in
>>> whatever level of css-ui it lands) with a provisional name of
>>>paint-order.
>>> If the target of a user event has a computed value of 'paint-order' for
>>> the pointer-events property, then user events (including CSS hover
>>> styling) would bubble through the same stack of elements returned by
>>> elementsFromPoint(). This would give us a true hover for positioned
>>> elements painted outside their parent's box, and allow fragment
>>>containers
>>> to respond to user events on their fragment content.
>>
>>Thanks for bringing this up, Alan.  This is what was provisionally
>>decided on at the face-to-face, and it would be great to get more
>>implementor feedback on it.
>>
>>+1, by the way.
>
>On today's teleconference, we resolved to add elementsFromPoint() to
>cssom-view and take up the pointer-events change later. Here is some
>proposed text for the cssom-view change. Simon or Glenn, could you get
>this into the editor's draft?
>
>   Add this line to the IDL in section 6:
>
>NodeList elementsFromPoint(double x, double y);
>
>   And then this definition:
>
>The elementsFromPoint(x, y) method must return the list of all elements
>under or intersecting the coordinates x,y in the viewport. The list to be
>returned is sorted by paint order, with the first element as the topmost
>in the order. If either argument is negative, x is greater than the
>viewport width excluding the size of a rendered scroll bar (if any), or y
>is greater than the viewport height excluding the size of a rendered
>scroll bar (if any), the method must return an empty NodeList. If there is
>no element at the given position the method must return a NodeList
>containing the root element, if any, or an empty NodeList otherwise. If
>there is no viewport associated with the document, the method must return
>an empty NodeList.
>
>   And perhaps an implementation note?
>
>The NodeList returned from elementsFromPoint(x, y) should be identical to
>a list constructed by iterating over these steps:
>
>1. Call elementFromPoint(x, y) and add any non-null result to the list.
>2. If the result not null nor the root element, remove that element and go
>to step 1.

Ah! A major point I forgot to add in. The NodeList returned should be
static, not live.

Thanks,

Alan
Received on Wednesday, 19 June 2013 22:14:47 UTC

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