- From: Gijs <notifications@github.com>
- Date: Tue, 19 Mar 2024 07:02:46 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/1265@github.com>
### What problem are you trying to solve? When dealing with custom elements, it is sometimes useful to find ancestor DOM elements outside of their respective shadow DOM. Without shadow DOM, this is easy to do by using the `closest` method. When shadow DOM is involved, this doesn't work, because `closest` will not cross shadow boundaries. ### What solutions exist today? [People end up hand-rolling helpers to address this](https://stackoverflow.com/questions/54520554/custom-element-getrootnode-closest-function-crossing-multiple-parent-shadowd). Those helpers are clunky and/or incorrect in some cases, and almost certainly slower than a browser-provided solution. It's obviously also possible to write a "manual" `parentNode`/`host` loop together with `matches()` to achieve the same thing, but again this is not very elegant and likely slower than a browser-provided solution. My understanding of `closest`'s purpose is that it's to avoid loops like that and for web content to be able to leverage the engine's speed and knowledge of the DOM to have something that is both more ergonomic as well as faster, so it feels like a failure of the API that in the shadow DOM / CE case we're back to using those "manual" methods to accomplish the same thing. ### How would you solve it? Add an optional options dictionary to the `closest` method similar to [the one that `getRootNode` has](https://dom.spec.whatwg.org/#dom-node-getrootnode) to allow people to specify `composed` or similar (not attached to the exact property name/description) to opt in to getting ancestor elements from outside the individual custom element's shadow DOM. ### Anything else? (this is a pretty bare-bones proposal based on running into this problem when writing an automated test, and so I'm happy to revise/edit as appropriate/necessary. It feels like a pretty small change compared to the storage API discussion linked in the contribution FAQ, so I'm guessing it doesn't need the same level of justification but I'm happy to be told I'm wrong about that.) -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/1265 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/dom/issues/1265@github.com>
Received on Tuesday, 19 March 2024 14:02:50 UTC