-
-
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
breaking: scope :has(...)
selectors
#13567
Conversation
The main part of #13395 This implements scoping for selectors inside `:has(...)`. The approach is to first descend into the contents of a `:has(...)` selector, then in case of a match, try to match the rest of the selector ignoring the `:has(...)` part. In other words, `.x:has(y)` is essentially treated as `x y` with `y` being matched first, then walking up the selector chain taking into account combinators. This is a breaking change because people could've used `:has(.unknown)` with `.unknown` not appearing in the HTML, and so they need to do `:has(:global(.unknown))` instead
🦋 Changeset detectedLatest commit: 3d436d6 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 |
// result in a invalid CSS output (e.g. `.x:has(/* unused .y */)`). The result | ||
// can't match a real element, so the only drawback is the missing prune. | ||
// TODO clean this up some day | ||
complex_selectors[0].metadata.used = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe put complex_selectors[0]
as its own better named variable. Why only the first element too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would just be called first_complex_selector
which IMO doesn't add any clarity.
As for why only the first: a complex selector is the a and b in :has(a, b)
. This logic is just there to prevent invalid CSS, which means we only need to mark one of them as used so there's at least one selector in there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this caused:
.dropzone:has(+ .dragenter-top),
:global(.dragenter-bottom + .dropzone) {
background-color: blue;
position: relative;
}
to trigger
editor:build: warnings when minifying css:
editor:build: ▲ [WARNING] Unexpected ")" [css-syntax-error]
editor:build:
editor:build: <stdin>:1230:71:
editor:build: 1230 │ ...) .dropzone:has(/* (unused) + .dragenter-top*/.svelte-12stbyo)*/
editor:build: ╵
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please open an issue with a reproduction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure: #13680
// and now looking upwards for the .x part. | ||
if ( | ||
apply_combinator( | ||
selectors[0]?.combinator ?? descendant_combinator, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe put selectors[0]
as its own better named variable. Why only the first element too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few nits, but overall it looks and works for me nicely locally too.
Hi, I just found a bug with this PR : something like |
We need to ignore the leading combinator within a `:has(...)`, else it would not stop matching, assuming there are more parent selectors (which there aren't) and always fail. #13567 (comment)
We need to ignore the leading combinator within a `:has(...)`, else it would not stop matching, assuming there are more parent selectors (which there aren't) and always fail. #13567 (comment)
The main part of #13395
This implements scoping for selectors inside
:has(...)
. The approach is to first descend into the contents of a:has(...)
selector, then in case of a match, try to match the rest of the selector ignoring the:has(...)
part. In other words,.x:has(y)
is essentially treated asx y
withy
being matched first, then walking up the selector chain taking into account combinators.This is a breaking change because people could've used
:has(.unknown)
with.unknown
not appearing in the HTML, and so they need to do:has(:global(.unknown))
insteadBefore submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.Tests and linting
pnpm test
and lint the project withpnpm lint