[@scope] Support '@import scope(...)' behind a flag #49178
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This CL implements the ability to scope an entire stylesheet on import, via the new scope() function. The CSSWG has resolved to add the scope() function, but there is no spec yet. The WPTs are therefore marked as tentative for now. Note that this CL intentionally does not have parse-validity tests, such as scope() combined with other features of the @import prelude (e.g. layer(), media queries). This is because scope()'s "position" in the prelude grammar has not been defined, and the WG instead resolved allow full reordering of the conditions. This opens a new problem, tracked by Issue 10972 [1]. In other words, parsing tests are deferred until that issue is resolved. The WPTs in this only use @import scope(...)", which is assumed to be valid regardless of the outcome. Since regular top-level selectors are not relative selectors, they are not guaranteed to contain either '&' or ':scope' like selector parsing nested under CSSNestingType::kNesting or CSSNestingType::kScope (respectively). This means that selectors at the top-level of an imported stylesheet are not guaranteed to be scope-containing, so we need another way of enforcing the in-scope [2] requirement of scoped selectors. This is effectively done by always treating the last selector in a complex selector as scope-containing. Due to the same absence of '&' and ':scope' in the imported stylesheet, rules can also be incorrectly handled as "easy" or "covered by bucketing" even though they match in the context of a scope. Addressed this by disabling the optimization when context.style_scope is set. [1] w3c/csswg-drafts#10972 [2] https://drafts.csswg.org/css-cascade-6/#in-scope Bug: 369876911 Change-Id: I75bc3514d959c6762232bc769f844682ed4a50fd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6012179 Commit-Queue: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1383152}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-6012179
branch
from
22078b3 to
3fcefd9
Compare
wpt-pr-bot
approved these changes
Nov 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This CL implements the ability to scope an entire stylesheet on import,
via the new scope() function. The CSSWG has resolved to add the scope()
function, but there is no spec yet. The WPTs are therefore marked as
tentative for now.
Note that this CL intentionally does not have parse-validity tests,
such as scope() combined with other features of the @import prelude
(e.g. layer(), media queries). This is because scope()'s "position"
in the prelude grammar has not been defined, and the WG instead resolved
allow full reordering of the conditions. This opens a new problem,
tracked by Issue 10972 [1]. In other words, parsing tests are
deferred until that issue is resolved. The WPTs in this only use
@import scope(...)", which is assumed to be valid regardless of the
outcome.
Since regular top-level selectors are not relative selectors,
they are not guaranteed to contain either '&' or ':scope'
like selector parsing nested under CSSNestingType::kNesting
or CSSNestingType::kScope (respectively). This means that selectors
at the top-level of an imported stylesheet are not guaranteed to
be scope-containing, so we need another way of enforcing
the in-scope [2] requirement of scoped selectors. This is effectively
done by always treating the last selector in a complex selector
as scope-containing.
Due to the same absence of '&' and ':scope' in the imported stylesheet,
rules can also be incorrectly handled as "easy" or
"covered by bucketing" even though they match in the context of a scope.
Addressed this by disabling the optimization when context.style_scope
is set.
[1] w3c/csswg-drafts#10972
[2] https://drafts.csswg.org/css-cascade-6/#in-scope
Bug: 369876911
Change-Id: I75bc3514d959c6762232bc769f844682ed4a50fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6012179
Commit-Queue: Anders Hartvoll Ruud <[email protected]>
Reviewed-by: Rune Lillesveen <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1383152}