Intent to Implement and Ship: elementsFromPoint

[Philip Rogers]

Primary eng/PM emails

p...@chromium.com

Spec

http://www.w3.org/TR/cssom-view/#extensions-to-the-document-interface

Summary

ElementsFromPoint is an API on Document for returning the sequence of elements under a point.

Motivation

Developers would like to determine all elements under a given point. There are existing polyfills for this (https://gist.github.com/oslego/7265412) which are significantly slower than this API will be.

Compatibility Risk

Firefox: No public signals

Internet Explorer: Shipped

Safari: No public signals

Web developers: Positive

Describe the degree of compatibility risk you believe this change poses

Low - There's a working draft spec and this is implemented (prefixed) in Internet Explorer 10.

Ongoing technical constraints

None

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux,

Chrome OS, and Android)? Yes

OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=448529

Entry in Chromium Dashboard

https://www.chromestatus.com/features/5743177185099776

Requesting approval to ship?

Yes - feature is relatively small.

[Levi Weintraub]

LGTM.

[Alan Stearns]

Non-official enthusiasm from me!

[Daniel Freedman]

Would a version for ShadowRoot be included as well, since it has elementFromPoint (singular)?

On Tue, Jan 13, 2015 at 3:31 PM, Alan Stearns <famu...@gmail.com> wrote:

Non-official enthusiasm from me!

[Rick Byers]

Great!

I know there is code out there that plays tricks to emulate this like call elementFromPoint in a loop, applying style.pointerEvents='none' to each element. It'll be nice to have a cleaner solution.

Maybe someday we should also drive a standard for elementsFromRect to enable fuzzy hit testing algorithms (like our touch adjustment) to be implemented in JS?

Rick

[Mike Lawther]

Just to double check - from what I can tell, IE implements both elementFromPoint (http://msdn.microsoft.com/en-us/library/ie/ms536417%28v=vs.85%29.aspx), and msElementsFromPoint (http://msdn.microsoft.com/en-us/library/ie/hh673523%28v=vs.85%29.aspx#The_msElementsFromPoint_method).

It's only the latter (that returns all elements) that we're proposing here right?

[Philip Rogers]

On Tue, Jan 13, 2015 at 4:12 PM, Daniel Freedman <dfr...@chromium.org> wrote:

Would a version for ShadowRoot be included as well, since it has elementFromPoint (singular)?

Great catch. It looks like elementsFromPoint, as specified, would not apply to ShadowRoots today. I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27829 to see if we can get that updated.

[Philip Rogers]

On Wed, Jan 14, 2015 at 7:27 PM, Mike Lawther <mikel...@chromium.org> wrote:

Just to double check - from what I can tell, IE implements both elementFromPoint (http://msdn.microsoft.com/en-us/library/ie/ms536417%28v=vs.85%29.aspx), and msElementsFromPoint (http://msdn.microsoft.com/en-us/library/ie/hh673523%28v=vs.85%29.aspx#The_msElementsFromPoint_method).

It's only the latter (that returns all elements) that we're proposing here right?

That's correct. We already support elementFromPoint.

I hope our implementing this will lead to Microsoft unprefixing msElementsFromPoint as well.

 

On Thu Jan 15 2015 at 2:09:37 PM Rick Byers <rby...@chromium.org> wrote:

Great!

I know there is code out there that plays tricks to emulate this like call elementFromPoint in a loop, applying style.pointerEvents='none' to each element. It'll be nice to have a cleaner solution.

Maybe someday we should also drive a standard for elementsFromRect to enable fuzzy hit testing algorithms (like our touch adjustment) to be implemented in JS?

+1, I had a developer ask for elementsFromRect yesterday to implement touch-drag selections.

[Justin Fagnani]

On Wed, Jan 14, 2015 at 7:09 PM, Rick Byers <rby...@chromium.org> wrote:

Great!

I know there is code out there that plays tricks to emulate this like call elementFromPoint in a loop, applying style.pointerEvents='none' to each element. It'll be nice to have a cleaner solution.

Maybe someday we should also drive a standard for elementsFromRect to enable fuzzy hit testing algorithms (like our touch adjustment) to be implemented in JS?

elementsFromRect() would be great, not just for fuzzy hit testing, but for drag-and-drop selection operations as seen in drawing tools and UI builders.

[Antonio Gomes]

Unofficial LGTM too.

elementsFromRect and elementsFromPoint could both be implemented using a rect-based hit test call, where the rect is (x, y, 1, 1) for the later and (x, y, w, h) for the former.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--

--Antonio Gomes

[Simon Pieters]

On Thu, 15 Jan 2015 04:09:13 +0100, Rick Byers <rby...@chromium.org> wrote:

> Great!
> I know there is code out there that plays tricks to emulate this like
> call
> elementFromPoint in a loop, applying style.pointerEvents='none' to each
> element. It'll be nice to have a cleaner solution.
>
> Maybe someday we should also drive a standard for elementsFromRect

> <http://msdn.microsoft.com/en-us/library/ie/hh673523%28v=vs.85%29.aspx#The_msElementsFromRect_method>

> to
> enable fuzzy hit testing algorithms (like our touch adjustment) to be
> implemented in JS?

Thanks, filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27837

--
Simon Pieters
Opera Software

[Philip Jägenstedt]

This sounds just great, LGTM!

Philip

[Philip Jägenstedt]

I see that our Document.elementFromPoint() takes long arguments and
not double. It would probably make sense to fix that for the same
release that gets Document.elementsFromPoint(), so that people don't
need to be tempted to use elementsFromPoint() just for the extra
precision.

Philip

[Rick Byers]

On Thu, Jan 15, 2015 at 10:20 AM, Philip Jägenstedt <phi...@opera.com> wrote:

I see that our Document.elementFromPoint() takes long arguments and
not double. It would probably make sense to fix that for the same
release that gets Document.elementsFromPoint(), so that people don't
need to be tempted to use elementsFromPoint() just for the extra
precision.

I assume that we're not planning on implementing sub-pixel hit-testing anytime soon (and so our implementation will round or truncate these values to integers - at least after applying the browser zoom factor), right?  All the hit-testing logic works on integers today, my feeling is that it's not worth the effort to overhaul it.  We have fractional input co-ordinates (for touch at least), but that's to enable smooth dragging, not more precise hit testing.  Even when fully pinch-zoomed in, I don't think you can position your finger precisely enough for it to really matter.  Stylus input + pinch-zoom or mouse input + browser zoom might be a different argument though.

[Christian Biesinger]

Hm? I thought we do our hit tests based on LayoutPoints?
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/rendering/HitTestLocation.h&sq=package:chromium&type=cs&l=37&rcl=1421094684

-christian

[Rick Byers]

On Thu, Jan 15, 2015 at 12:52 AM, Antonio Gomes <toni...@gmail.com> wrote:

Unofficial LGTM too.

elementsFromRect and elementsFromPoint could both be implemented using a rect-based hit test call, where the rect is (x, y, 1, 1) for the later and (x, y, w, h) for the former.

Note that there may be some work necessary to improve/validate our rect-based hit-testing logic.  We rely on a redundant point-based hit-test today to resolve a rect-based hit-test to a single node: http://crbug.com/398914.  When I tried to remove the extra hit test we had a long tail of subtle targeting regressions (not necessarily bugs in rect-based hit-testing, but may be) so I was forced to add it back.  But I'd be happy for an excuse to dig into each of these issues and ensure rect-based hit-testing is robust.

Rick

[Rick Byers]

D'oh - of course you're right!  Clearly I was mis-remembering.

Mouse/gesture input is in integer DIPs, so we don't make use of non-integer hit-tests in mainline high-dpi scenarios (I don't think you can even position the mouse cursor at non-integer DIP co-ordinates - at least on MacOS).  But apparently we do handle the scale transform cases down to LayoutUnit granularity (pinch-zoom, browser zoom, etc.).  Thanks!

Rick

[Tab Atkins Jr.]

LGTM, definitely.

[Chris Harrelson]

LGTM

> email to blink-dev+unsubscribe@chromium.org.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Jochen Eisinger]

lgtm3

[Philip Rogers]

The ShadowDom spec was recently amended[1] to support ShadowRoot.elementsFromPoint(), similar to the existing ShadowRoot.elementFromPoint. I'm not sure this warrants another intent to ship but I wanted to update this thread in case there are concerns.

[1] http://w3c.github.io/webcomponents/spec/shadow/#widl-ShadowRoot-elementsFromPoint-sequence-Element--double-x-double-y

[Philip Jägenstedt]

Sounds good to me!

Dimitri and Hayato, your spec seems to be broken, it's not generating
a table of contents or the IDL sections. With WebVTT, I publish a
static copy to make it load faster and so that ReSpec changes can't
break it.

Philip

>>>> > email to blink-dev+...@chromium.org.

>>>>
>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>> an email to blink-dev+...@chromium.org.

>
>
> To unsubscribe from this group and stop receiving emails from it, send an

> email to blink-dev+...@chromium.org.

[Hayato Ito]

On Tue, Mar 3, 2015 at 11:19 AM Philip Jägenstedt <phi...@opera.com> wrote:

Sounds good to me!

Dimitri and Hayato, your spec seems to be broken, it's not generating
a table of contents or the IDL sections. With WebVTT, I publish a
static copy to make it load faster and so that ReSpec changes can't
break it.

Thanks for letting me know that. Looks ReSpec complains:

> GET https://labs.w3.org/specrefs/bibrefs?refs=RFC2119,DOM,HTML,CSS21,SELECTORS4…-Level-3-Events,TOUCH-EVENTS,EDITING,CSS3UI,WAI-ARIA,CSSOM-VIEW,DOMPARSING 

> net::ERR_CONNECTION_TIMED_OUT

Let me investigate further.

 

>>>> > email to blink-dev+unsubscribe@chromium.org.

>>>>
>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>> an email to blink-dev+unsubscribe@chromium.org.

>
>
> To unsubscribe from this group and stop receiving emails from it, send an

> email to blink-dev+unsubscribe@chromium.org.

[Hayato Ito]

Since https://labs.w3.org/ looks down, all specs which use ReSpec aren't rendered properly. I've pinged Mike Smith at #whatwg IRC.