- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 18 Oct 2018 13:30:33 +0000
- To: public-css-archive@w3.org
Right. So the deal is, we're excluding `display:contents` elements (of which `slot`s usually are) for a reason - there's no way to *click* on such an element, because it doesn't exist on the page. You can click on its contents, sure, but that's something different. Here's an example of why this makes sense: if you call `elementsFromPoint()`, you'll *often* get the full ancestor chain of the clicked element, because usually descendants are contained within the geometry of ancestors. But if you use abspos or something to move an element outside the ancestor's geometry, then when you click on the child the ancestor does *not* show up, because it's not underneath the mouse click. If the parent of the abspos is `display:contents`, should it be returned or not? It doesn't have any dimensions; if we return it in the list, and people then check its bounds, they won't contain the point that was clicked. (For example, see <http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6290>.) If we don't return such an element in *this* situation, we shouldn't return it from elementFromPoint(), just because it happens to be the parent node of some clicked text; elementFromPoint() should always return the first element of the array returned by elementsFromPoint(). So yeah, insofar as capturing a useful notion of what text was clicked is important (and I agree it is), what you want is nodeFromPoint(), so we can return the text node, rather than trying to do some tricky nonsense with elementFromPoint() to return an element that is literally *not at the specified point*. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/556#issuecomment-431009002 using your GitHub account
Received on Thursday, 18 October 2018 13:30:35 UTC