-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
fix(compiler-sfc): don't inject scope id before child combinator > #13389
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
Conversation
WalkthroughA new test was added to verify the correct handling of scoped CSS with direct child combinators and universal selectors. The implementation was updated to prevent attribute injection for selectors starting with a child combinator, while ensuring attribute selectors are still applied to trailing universal selectors, clarifying the control flow. Changes
Sequence Diagram(s)sequenceDiagram
participant TestRunner
participant Compiler
participant StylePlugin
TestRunner->>Compiler: Compile SFC with scoped CSS (e.g., main > *)
Compiler->>StylePlugin: Process selectors for scoping
StylePlugin-->>Compiler: Inject attribute selectors appropriately
Compiler-->>TestRunner: Return compiled CSS with correct scoping
Assessment against linked issues
Possibly related PRs
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (3)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
@vue/compiler-core
@vue/compiler-dom
@vue/compiler-ssr
@vue/compiler-sfc
@vue/reactivity
@vue/runtime-core
@vue/runtime-dom
@vue/server-renderer
@vue/shared
vue
@vue/compat
commit: |
Size ReportBundles
Usages
|
/ecosystem-ci run |
4e0c3e9
to
9092ced
Compare
📝 Ran ecosystem CI: Open
|
9092ced
to
522077b
Compare
More generally, why do we include the scope id earlier in the selector for e.g. Why does I believe these 3 CSS rules should all be considered equivalent: div > * {
color: red;
}
div {
> * {
color: red;
}
}
div {
& > * {
color: red;
}
} This PR seems like a step in the right direction, but the middle rule is still being handled differently from the other two. |
// #13387 don't inject [id] at the selector start if node is null | ||
// and the selector starts with `>` | ||
const { type, value } = selector.first | ||
if (type === 'combinator' && value === '>') { |
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.
Is there a reason to handle >
differently from other combinators?
Other combinators can come first in a nested selector, see https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting/Using_CSS_nesting#combinators. Combinators such as +
seem to suffer from the same problem as >
when used with *
.
I've created #13405 for further discussion of how to handle trailing |
close #13387
Summary by CodeRabbit
Bug Fixes
main > *
), ensuring accurate style scoping.Tests