[@scope] Support '@import scope(...)' behind a flag
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 andruud@chromium.org
Reviewed-by: Rune Lillesveen futhark@chromium.org
Cr-Commit-Position: refs/heads/main@{#1383152}