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.

> 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