Re: [csswg-drafts] [cssom-view] elementFromPoint, elementsFromPoint, and caretPositionFromPoint should not return an element inside a shadow tree (#556)

The CSS Working Group just discussed `[cssom-view] elementFromPoint, elementsFromPoint, and caretPositionFromPoint should not return an element inside a shadow tree`, and agreed to the following:

* `ACTION: Add test to WPT`
* `RESOLVED: These methods use the DOM retargetting rules to omit elements inside shadow trees and remove consecutive duplicates that result from these`
* `ACTION: File a separate issue about potentially adjusting the offset`

<details><summary>The full IRC log of that discussion</summary>
&lt;ydaniv> scribe+<br>
&lt;flackr> scribe+<br>
&lt;flackr> emilio: This is about a handful of cssom apis that don't expose nodes from shadow trees, but it's not well spec'd how<br>
&lt;emilio> https://github.com/w3c/webcomponents/issues/736<br>
&lt;emilio> https://searchfox.org/firefox-main/rev/6087999d87e808ec39f260293afd6cc27b6c5944/dom/base/DocumentOrShadowRoot.cpp#451-455<br>
&lt;flackr> emilio: I think spec'ing what gecko implements is not too hard. We retarget all of the nodes using the regular retargeting algorithms like active element but we avoid duplicates<br>
&lt;flackr> emilio: If two nodes inside the shadow tree would show up in elementsFromPoint, instead of getting the host twice you get it once.<br>
&lt;flackr> emilio: I suspect there are some interesting edge cases where the host can legitimately show up twice, e.g. [missed], but i think this is okay<br>
&lt;flackr> emilio: I'm not familiar with what other browsers implement. I think this is reasonably interoperable<br>
&lt;flackr> emilio: doing what gecko does seems reasonable. If anyone knows what other browsers do would invite comments<br>
&lt;flackr> emilio: I propose spec'ing this<br>
&lt;emilio> astearns: rniwa linked to some WebKit code but don't know what that does off the top of my head<br>
&lt;emilio> smfr: can you point me to the link?<br>
&lt;astearns> https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/shadow-dom/DocumentOrShadowRoot-prototype-elementFromPoint.html<br>
&lt;fantasai> https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/shadow-dom/DocumentOrShadowRoot-prototype-elementFromPoint.html<br>
&lt;emilio> astearns: it's a layout test<br>
&lt;emilio> smfr: if you run script in a shadow tree can you call elementsFromPoint?<br>
&lt;flackr> emilio: There's a shadowroot.elementsfrompoint you can call, that only targets things in inner shadow trees<br>
&lt;emilio> https://searchfox.org/wubkat/rev/68f2a0d2a5f6fc91cbfb573ccf94fceaaa2f162c/Source/WebCore/dom/TreeScope.cpp#464,468,474-480<br>
&lt;flackr> emilio: this is the same concept as all the dom retargeting code<br>
&lt;flackr> emilio: The webkit code seems to be doing something similar to what FF does<br>
&lt;emilio> astearns: so emilio you're proposing that these would use the retargetting rules and omit duplicates<br>
&lt;flackr> emilio: that sounds right<br>
&lt;flackr> emilio: basically, retarget the node before returning it to script. If it matches the last node don't append it, otherwise append it<br>
&lt;dbaron> Chromium code at https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/tree_scope.cc;l=377-380;drc=b4528fe64d8704dc89748f6e371c7f97b13da16f omits duplicates but only if they're consecutive<br>
&lt;emilio> astearns: the issue is blink behavior is not doing retargetting?<br>
&lt;flackr> emilio: comments in the issue suggest blink is retargeting now<br>
&lt;emilio> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/tree_scope.cc;l=297-299;drc=b4528fe64d8704dc89748f6e371c7f97b13da16f<br>
&lt;flackr> emilio: looking at blink code, it looks like it is doing effectively the same thing<br>
&lt;flackr> emilio: so it seems all engines effectively are doing this retargeting, possibly with minor differences tests may uncover<br>
&lt;emilio> astearns: so can we resolve that these would use the retargetting rules and omit duplicates?<br>
&lt;emilio> astearns: spec that, check the tests and see if that can fly<br>
&lt;flackr> dbaron: do other engines detect duplicates out of order?<br>
&lt;flackr> emilio: no<br>
&lt;flackr> dbaron: that's probably detectable if things in the shadow root have interesting z-indices<br>
&lt;flackr> emilio: yes, this is<br>
&lt;flackr> dbaron: might need to specify that, it is weird<br>
&lt;flackr> emilio: it is true though<br>
&lt;flackr> emilio: I can't justify any other behavior<br>
&lt;emilio> emilio: maybe omitting the next one<br>
&lt;emilio> dbaron: maybe flackr has opinions<br>
&lt;emilio> flackr: the proposed behavior seems reasonable, seems fine to have dupes if they're interposed in stacking order<br>
&lt;emilio> PROPOSED: These methods use the DOM retargetting rules to omit elements inside shadow trees and remove consecutive duplicates that result from these<br>
&lt;fantasai> ACTION: Add test to WPT<br>
&lt;emilio> RESOLVED: These methods use the DOM retargetting rules to omit elements inside shadow trees and remove consecutive duplicates that result from these<br>
&lt;fantasai> emilio: caretPositionFromPoint may need to retarget, but only returns one node ...?<br>
&lt;flackr> emilio: This mostly applies to elementsFromPoint right? caretPositionFromPoint might also need to retarget but it only returns one node?<br>
&lt;emilio> fantasai: I think we need to look at the caretPositionFromPoint offset<br>
&lt;emilio> emilio: yeah I think we need to retarget the node but what to do with the offset is interesting<br>
&lt;fantasai> ACTION: File a separate issue about potentially adjusting the offset<br>
&lt;emilio> astearns: separate issue?<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/556#issuecomment-4389522680 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 6 May 2026 15:19:13 UTC