W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: [cssom-view] Need a variant of elementFromPoint that returns a NodeList

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 08 Feb 2011 19:38:49 -0800
Message-ID: <4D520C49.8010109@jumis.com>
To: www-style@w3.org
CC: Simon Fraser <smfr@me.com>, "esprehn@gmail.com" <esprehn@gmail.com>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>
On 2/8/2011 7:25 PM, Simon Fraser wrote:
> On Feb 8, 2011, at 7:01 PM, esprehn@gmail.com wrote:
>
>> On Tue, Feb 8, 2011 at 3:31 PM, Simon Fraser<smfr@me.com>  wrote:
>>> On Feb 8, 2011, at 3:22 PM, 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.
>>> I'm glad you said static!
>>>
>>> Why would you want to return a node that can never be hit by the user?
>>>
>>> If the author wants to make a node invisible to user events, they can use
>>> the pointer-events property.
>> 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 for the explanation. I think this is a reasonable request.
>
> Simon

On this same point -- did the event.mouseCoords() style proposal get any 
further?
This is on topic, though it's at the other end of the spectrum.

When CSS 2D transforms get thrown in the mix, matching the mouse 
coordinates to the
coordinates stored in a scripting environment gets pretty tricky. I've 
had to add two layers onto every
piece of UI that I do. It'd be nice to route it through a function if it 
exists, and return early, and let
the UA handle the transformation chain.

[body onload="scrollTo(... somewhere...)"]
[canvas style="transform: scale(2,2); padding-top: 2em; margin-top: 
2em;"][/canvas]

-Charles
Received on Wednesday, 9 February 2011 03:39:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:37 GMT