Tab, Yeah, I think it makes sense to return all elements as if pointer-events is auto. I'm not sure the flag is worth the complexity since it's pretty trivial to implement pointer-events special handling if the user wants to. For the SVG cases of pointer-events: visibleFill, etc, SVG has isPointInFill and isPointInStroke. A case where you would not filter out pointer-events: none is when you are building a WYSIWYG editor that supports pointer-events: none elements. On Thu, Feb 26, 2015 at 2:09 AM, Simon Pieters <simonp@opera.com> wrote: > On Wed, 25 Feb 2015 22:40:50 +0100, Philip Rogers <pdr@google.com> wrote: > > www-style, >> >> The elementsFromPoint (plural) spec [1] is ambiguous about whether >> elements >> with pointer-events: none should be returned. Can we update the spec to >> explicitly allow pointer-events: none elements? >> >> I think it makes sense to return all elements and have this be a >> general-purpose API. I spoke with a front-end developer on the polymer >> team >> and they agreed because typical usecases already need to filter out >> unwanted elements. The IE team may have come to the same conclusion as >> msElementsFromPoint also includes pointer-events: none elements. >> >> [1] http://www.w3.org/TR/cssom-view/#extensions-to-the-document-interface >> > > For which use cases would you not filter them out? > > -- > Simon Pieters > Opera Software >
Received on Thursday, 26 February 2015 21:42:53 UTC