-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Svelte 5: Non-top-level :has()
selector is considered unused
#13717
Comments
This is a huge deal-breaker for me. Above workaround does not work in this example: <!-- Unused CSS selector "fieldset:has(legend) > legend" -->
<style lang="postcss">
fieldset:has(legend) {
@apply border-2 p-4;
}
fieldset:has(legend) > legend {
@apply -ml-3 px-3 font-bold;
}
</style> Considering this case, the issue title should be updated as well. |
Fixes #13717 There are two parts to this: 1. the parent selectors weren't passed along for the check inside `:has`, which in case of a leading combinator would mean it would always count as unused 2. In case if a selector like `x > y:has(z)`, the prior logic would correctly determine that for element `z` there's a match for the `:has` selector, by first checking its contents and then walking up the tree. But after it did that, it would try to walk up the tree once more, which is a) wasteful b) buggy because the tree walking mechanism would no longer be adjusted for the `:has` special case, resulting in false negatives. To fix that, the `:has` will return a new value from the function, signaling that it already fully checked the upper selectors, and so the function calling it will skip doing that.
…13750) Fixes #13717 There are two parts to this: 1. the parent selectors weren't passed along for the check inside `:has`, which in case of a leading combinator would mean it would always count as unused 2. In case if a selector like `x > y:has(z)`, the prior logic would correctly determine that for element `z` there's a match for the `:has` selector, by first checking its contents and then walking up the tree. But after it did that, it would try to walk up the tree once more, which is a) wasteful b) buggy because the tree walking mechanism would no longer be adjusted for the `:has` special case, resulting in false negatives. To fix that, the `:has` will return a new value from the function, signaling that it already fully checked the upper selectors, and so the function calling it will skip doing that.
@dummdidumm thank you for the fix. Unfortunately, as of <label>
<input type="checkbox" />
<span>I am red when checked</span>
</label>
<style>
label:has(input:checked) span {
color: red;
}
</style>
Happy to open a separate issue, just let me know if needed. Thanks! UPDATE: not any sorry. I looked into the test cases for :has. The equivalence of the above issue is: Input: <x>
<y></y>
<w></w>
</x>
<style>
x:has(y) w {
color: green;
}
</style> Expected: x.svelte-xyz:has(y:where(.svelte-xyz)) w:where(.svelte-xyz) {
color: green;
} which wasn't covered yet as of |
Describe the bug
The
<legend>
element appears as[email protected]
- Yellow (Broken)[email protected]
- Red (Expected)I don't think this is an intended change of the following PR, because
<legend>
clearly appears in the markup.:has(...)
selectors #13567Reproduction
Logs
No response
System Info
Severity
blocking an upgrade
The text was updated successfully, but these errors were encountered: