feat: implement support for :is(...) and :where(...)
#10490
Conversation
🦋 Changeset detectedLatest commit: 094f2b1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
* parse nested CSS * tests * track parent rules * some progress * switch it up * pruning * works * changeset * lint * error early on invalid nesting selector * tidy * note to self * fix some specificity stuff * failing test * note to self * fix: correctly scope CSS selectors with descendant combinators (#10502) * fix traversal, but break some other stuff * man this is fucken hard * fixes * getting closer * be conservative for now * tidy * invert * invert * simplify * switch * for now * progress * i think it works? * fix * tidy up * revert some stuff * remove some junk * handle weird cases * update * tweak * shrink * changeset --------- Co-authored-by: Rich Harris <[email protected]> --------- Co-authored-by: Rich Harris <[email protected]>
| * @param {import('#compiler').Css.ComplexSelector} node | ||
| */ | ||
| function truncate(node) { | ||
| const i = node.children.findLastIndex(({ metadata }) => { |
There was a problem hiding this comment.
Is it possible that i might be -1 here?
There was a problem hiding this comment.
Yes, and that's fine because we do array.slice(0, -1 + 1) which gives us an empty array, which is exactly what we want
| } | ||
|
|
||
| return false; | ||
| default: | ||
| // TODO other combinators |
There was a problem hiding this comment.
Isn't it better to throw an error if we're missing a combinator?
There was a problem hiding this comment.
No, it's better to just be conservative and include the CSS — removing it is an optimisation. The only combinator we're missing is ||. If another combinator is added to the language, all we need to do (until we have time to implement pruning for it, which may be prohibitively difficult) is adjust a regex
| if (child.type === 'Rule' && is_used(child)) return true; | ||
|
|
||
| if (child.type === 'Atrule') { | ||
| return true; // TODO |
There was a problem hiding this comment.
that we don't yet analyse atrules to determine whether they are used in the context of the current component. it was there before this PR but in a different place
This PR implements proper support for
:is(...)and:where(...).In Svelte 4, these are ignored for scoping purposes, like other pseudo-classes that aren't
:global(...). The outcome is that a selector like this......becomes this:
This is slightly unhelpful:
class="bar"element, not just those defined within the component. That might not be what you want.unusedclassname is kept, even though it's... unusedAs of this PR, we get this instead:
This behaviour is more desirable. If you do want the old 'match any
class="bar"descendant' behaviour, you can easily achieve that with:global(...):Implementing this is a necessary precursor to nested CSS support, since it involves the same recursive mechanism.
Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.Tests and linting
pnpm testand lint the project withpnpm lint