Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an optional options dictionary to closest to allow jumping across shadow boundaries #1265

Open
gijsk opened this issue Mar 19, 2024 · 1 comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: shadow Relates to shadow trees (as defined in DOM)

Comments

@gijsk
Copy link

gijsk commented Mar 19, 2024

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

@gijsk gijsk added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Mar 19, 2024
@annevk annevk added the topic: shadow Relates to shadow trees (as defined in DOM) label Mar 19, 2024
@annevk
Copy link
Member

annevk commented Mar 19, 2024

I'm not sure how scoping root would have to be amended as Selectors do not match across the boundary. I guess we could just not provide a scoping root once you cross the boundary. (This impacts :scope.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: shadow Relates to shadow trees (as defined in DOM)
Development

No branches or pull requests

2 participants