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

On Wed, 09 Feb 2011 00:22:37 +0100, Ian Hickson <ian@hixie.ch> 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, esprehn@gmail.com 
<esprehn@gmail.com> 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:
> http://stackoverflow.com/questions/1280660/given-an-x-y-coordinate-i-need-to-find-all-html-elements-underneath-it
> http://bytes.com/topic/javascript/answers/89463-finding-all-elements-specific-coordinates
> http://www.vinylfox.com/forwarding-mouse-events-through-layers/
>
> 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: 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19753

-- 
Simon Pieters
Opera Software

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