Bug 19753 - Add plural versions of document.elementFromPoint() and document.caretPositionFromPoint()
Add plural versions of document.elementFromPoint() and document.caretPosition...
Status: RESOLVED FIXED
Product: CSS
Classification: Unclassified
Component: CSSOM View
unspecified
All All
: P2 enhancement
: ---
Assigned To: Simon Pieters
public-css-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-29 07:33 UTC by Sebastian Zartner
Modified: 2013-08-08 13:28 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Zartner 2012-10-29 07:33:14 UTC
document.elementFromPoint() and document.caretPositionFromPoint() are defined to use hit testing to return the uppermost element resp. a range related to it at a specific viewport point.
To cover use cases, which need to know about the other elements at that coordinates than just the uppermost one, there should be plural forms of them returning the elements or ranges sorted descending by their z-order.

There's a related discussion:
http://lists.w3.org/Archives/Public/www-style/2012Oct/0804.html

Sebastian
Comment 1 Simon Pieters 2013-04-16 10:56:52 UTC
I noticed IE supports something like this:

http://ie.microsoft.com/testdrive/HTML5/HitTest/

Should I spec IE's msElementsFromPoint()? What about msElementsFromRect()?

Should elements that would not be a target for hit testing (e.g. because it has pointer-events:none) be included in the list?
Comment 2 Sebastian Zartner 2013-04-16 12:49:31 UTC
I just realized that there was an earlier discussion on this[1].

> Should I spec IE's msElementsFromPoint()? What about msElementsFromRect()?
If you're asking me, this seems reasonable.

> Should elements that would not be a target for hit testing (e.g. because it has 
> pointer-events:none) be included in the list?
Firefox and Chrome already do this for document.elementFromPoint().
I tend to say that it should not work that way, since calling the function is unrelated to pointer events. And the matched elements can easily be sorted out by looping over them.
In any case it should be defined to be consistent with the behavior of document.elementFromPoint().

Sebastian

[1] http://lists.w3.org/Archives/Public/www-style/2011Feb/0264.html
Comment 3 Simon Pieters 2013-06-24 10:37:15 UTC
In Chrome/Firefox/IE10, elementFromPoint does not return the top-most element if it has pointer-events:none. (Tested with SVG's pointer-events="none" for IE.)

In IE10, msElementsFromPoint includes elements with pointer-events="none".

So it's not consistent, but maybe what IE10 does is best -- if you ask for all elements at a point, we should include all of them, and the developer can filter out manually if those with pointer-events:none are not wanted. For elementFromPoint, we have interop and it seems plausible to want the element that would be targeted when that position is clicked.
Comment 4 Simon Pieters 2013-06-24 11:26:44 UTC
https://dvcs.w3.org/hg/csswg/rev/ef0951c69a81
https://dvcs.w3.org/hg/csswg/rev/c1e5017eca4c

What's the use case for a plural form of caretPositionFromPoint? (Please file a new bug for that.)
Comment 5 Sebastian Zartner 2013-06-25 14:07:54 UTC
> What's the use case for a plural form of caretPositionFromPoint?
I currently can't think of a good use case. The only thing that came to my mind were overlapping text fields or text areas used for auto-completion. Though there you might not necessarily need to know the caret position inside the overlapped element.
I'll ask for better use cases in the list and report a new issue if necessary.

Sebastian
Comment 6 Sebastian Zartner 2013-06-25 14:25:30 UTC
Asking here:
http://lists.w3.org/Archives/Public/www-style/2013Jun/0561.html

Sebastian