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

On Wed, 09 Feb 2011 00:22:37 +0100, Ian Hickson <> wrote:

> elementFromPoint() is defined to return a single Element, but apparently
> it is quite common for users of this API to find that the element at the
> given point isn't the element they want, because multiple elements are
> overlaid on the same spot on the canvas.
> It would be useful for such users if a variant of this API could be made
> that returns a (static) NodeList giving all the elements under that point.
> (Note that crawling the DOM is not sufficient here, because the 
> overlapped
> nodes are often from very different parts of the DOM, apparently.)
> I've cc'ed Elliott, who may be able to provide more information about use
> cases and might be able to show examples of other Wev devs asking for 
> this
> kind of thing.
On Wed, 09 Feb 2011 04:01:59 +0100, 
<> wrote:
> The issue is not making the element invisible to user events, but
> selecting a "meaningful" element. For instance there's many extensions
> for browsers right now where you can draw on top of the page. It'd be
> useful to be able to select the nearest meaningful element (perhaps an
> entire paragraph of text, even though I clicked a single letter).
> When you account for positioning, a "glass" overlay, and many other
> factors elementFromPoint is difficult to use. That is, what you get
> back may be the glass overlay you put on the page, or it might be an
> absolutely positioned element that's actually invisible to the user
> (that just exists above part of the paragraph of text), or maybe it's
> a tiny image that's been absolutely positioned there, but the most
> "meaningful" element is the entire bordered area around the image.
> Right now we have to:
> 1. Hide the glass
> 2. Use elementFromPoint()
> 3. See if the element is meaningful
> 4. If not meaningful hide this element and call elementFromPoint() again.
> We've seen noticeable flicker from some browsers as the result of this.
> Here's other people trying to implement the same thing:
> The last link does exactly what we do. Hide the mask, call
> elementFromPoint() and show it again.
> What I'm proposing is a way to "slice" all the way through the page on
> the z axis and get back a static node list so this wouldn't be an
> issue.
Thanks, that's helpful.

On 6/19/13 11:09 PM, Alan Stearns wrote:
> 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.
Done (except I used sequence).
>     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.
That would be incorrect, since elementFromPoint uses hit testing.

There's also a bug for this issue:

Simon Pieters
Opera Software

Received on Monday, 24 June 2013 11:27:57 UTC