fix: correctly visit elements that may match :has() during pruning
#15207I've got some complex sibling combinator + :has
css selectors that match the DOM but are reported as unused by Svelte. Through further testing, it appears that some trivial cases are incorrectly marked as unused.
./packages/svelte/tests/css/samples/has/input.svelte
style
blockx:has(+ c) {
color: green;
}
x:has(~ c) {
color: green;
}
Notice that these are valid selectors based on the given DOM structure
css_unused_selector
errors. I've found that wrapping c
in :global()
seems to get rid of the errors, but I'm not sure if that should be required to get this selector working.No response
Svelte Version - 5.1.6
annoyance
Fixes #14072
:has()
was matching only against descendants or siblings, but not sibling's descendants.
Also, in a case like :has(> .foo > .bar)
it was matching against children instead of descendants, so I had to drop the >
optimization. But, to ensure that in case like :has(> .foo)
it matches only the direct children, the inner selector is prepended with a selector of new type that matches only certain element.
feat:
, fix:
, chore:
, or docs:
.packages/svelte/src
, add a changeset (npx changeset
).pnpm test
and lint the project with pnpm lint
Latest commit: b41004a
The changes in this PR will be included in the next version bump.
Name | Type |
---|---|
svelte | Patch |
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
pnpm add https://pkg.pr.new/svelte@15207
So, now :has()
sometimes is very far from being optimal. The correct way is to call forward-going apply_selector
and other functions, but currently they are backward-going. So I have an idea of making them bidirectional instead. I'll try it later.
Closing in favor of #15277