- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 24 Jun 2013 13:29:19 +0200
- To: Alan Stearns <stearns@adobe.com>
- CC: W3C WWW Style <www-style@w3.org>, "glenn.adams@cox.com" <glenn.adams@cox.com>, Ian Hickson <ian@hixie.ch>, Elliott Sprehn <esprehn@gmail.com>, Simon Fraser <smfr@me.com>
On Wed, 09 Feb 2011 00:22:37 +0100, Ian Hickson <ian@hixie.ch> 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. > > (Note that crawling the DOM is not sufficient here, because the > overlapped > nodes are often from very different parts of the DOM, apparently.) > > I've cc'ed Elliott, who may be able to provide more information about use > cases and might be able to show examples of other Wev devs asking for > this > kind of thing. On Wed, 09 Feb 2011 04:01:59 +0100, esprehn@gmail.com <esprehn@gmail.com> wrote: > 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, that's helpful. On 6/19/13 11:09 PM, Alan Stearns wrote: > On today's teleconference, we resolved to add elementsFromPoint() to > cssom-view and take up the pointer-events change later. Here is some > proposed text for the cssom-view change. Simon or Glenn, could you get > this into the editor's draft? Add this line to the IDL in section 6: > NodeList elementsFromPoint(double x, double y); And then this > definition: The elementsFromPoint(x, y) method must return the list of > all elements under or intersecting the coordinates x,y in the > viewport. The list to be returned is sorted by paint order, with the > first element as the topmost in the order. If either argument is > negative, x is greater than the viewport width excluding the size of a > rendered scroll bar (if any), or y is greater than the viewport height > excluding the size of a rendered scroll bar (if any), the method must > return an empty NodeList. If there is no element at the given position > the method must return a NodeList containing the root element, if any, > or an empty NodeList otherwise. If there is no viewport associated > with the document, the method must return an empty NodeList. Done (except I used sequence). > And perhaps an implementation note? > > The NodeList returned from elementsFromPoint(x, y) should be identical to > a list constructed by iterating over these steps: > > 1. Call elementFromPoint(x, y) and add any non-null result to the list. > 2. If the result not null nor the root element, remove that element and go > to step 1. That would be incorrect, since elementFromPoint uses hit testing. There's also a bug for this issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19753 -- Simon Pieters Opera Software
Received on Monday, 24 June 2013 11:27:57 UTC