This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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?
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
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.
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.)
> 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
Asking here: http://lists.w3.org/Archives/Public/www-style/2013Jun/0561.html Sebastian