Description
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. 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 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.)