Intent to Ship: @scope

[Anders Hartvoll Ruud]

Contact emails

and...@chromium.org

Explainer

https://css.oddbird.net/scope/explainer

Specification

https://drafts.csswg.org/css-cascade-6/#scope-atrule

Summary

Allows authors to scope style rules to a given element. The key differences between this and regular descendant combinators are:

• The scope proximity cascade criterion, which makes it possible to weigh the priority of declarations according to the distance to a given scoping element.

• The scoping limit, which makes it possible for a rule to apply to elements within a given subtree, but only until some specified “lower bound”.

Example:

<style>

  @scope (.foo) to (.limit) {

    .green { background-color: green; }

  }

</style>

<div class=foo>

  <div class=green>Green</div>

  <div class=limit>

      <div class=green>Not green (within .foo, but below .limit)</div>

  </div>

</div>

<div class=green>Not green (not within .foo)</div>

Authors can also automatically scope the styles to <style>’s parent element by dropping the selector(s) in @scope’s prelude:

<div>

  <style>

    @scope {

      .green { background-color: green; }

    }

  </style>

  <div class=green>Green</div>

</div>

<div class=green>Not green</div>

Blink component

Blink>CSS

TAG review

https://github.com/w3ctag/design-reviews/issues/593

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Gecko: Under consideration (https://github.com/mozilla/standards-positions/issues/472)

WebKit: Positive (https://github.com/WebKit/standards-positions/issues/13)

Web developers: Positive (https://2022.stateofcss.com/en-US/usage/#missing_features_freeform)

See also emoji excitement on this post to bring back scoped styles: https://github.com/w3c/csswg-drafts/issues/3547

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? No.

Debuggability

The @scope rule is supported by DevTools. Style rules within @scope appear as they should, and the prelude of the enclosing @scope rule is shown similar to how rules within @media appear.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Most of the feature is covered. (wpt.fyi tests)

• The failing test scope-shadow.html will be addressed before release.

• The remaining WPT gaps will be closed before release. crbug.com/1450473

Flag name

CSSScope

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1280240

Estimated milestones

M117

Anticipated spec changes

There are no anticipated spec changes that would break compatibility. We may extend this feature with additional capabilities in the future, notably:

• The :scope-end pseudo-class. https://github.com/w3c/csswg-drafts/issues/8617 

• Combinators (>>, ~~). https://github.com/w3c/csswg-drafts/issues/8628 

• Sibling scopes. https://github.com/w3c/csswg-drafts/issues/7751

The above additions would not change the behavior of what's shipping in this intent, and is just included as a preview of what might come later.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5100672734199808

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/O2xZZT_xCZM/m/1dPDpV-MCgAJ

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

LGTM1

This seems like an obvious useful addition with relatively broad consensus around it. Thanks for working on this!

On Thu, Jun 1, 2023 at 10:39 AM Anders Hartvoll Ruud <and...@chromium.org> wrote:

Contact emails

and...@chromium.org

Explainer

https://css.oddbird.net/scope/explainer

+Miriam Suzanne - that's a great explainer!! (and by far the most stylish one I've ever seen)

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUo585eMqqfxYsK65h53aT-eUCwAyYak%2BRFW40%3DtUxnMDg%40mail.gmail.com.

[Miriam Suzanne]

Haha, good to hear - thanks.

Cheers, 

-Miriam

[Chris Harrelson]

LGTM2!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6c39ac28-3157-44a2-bd0d-5aa2c6f92823%40Spark.

[Artur Janc]

I'm wondering how @scope will interact with :visited (to make sure we avoid exposing the visitedness of links as per https://dbaron.org/mozilla/visited-privacy) -- are all links treated as unvisited for the purposes of @scope?

[Anders Hartvoll Ruud]

On Tue, Jun 6, 2023 at 4:07 PM Artur Janc <a...@google.com> wrote:

I'm wondering how @scope will interact with :visited (to make sure we avoid exposing the visitedness of links as per https://dbaron.org/mozilla/visited-privacy)

 

The exact privacy measures related to :visited/:link (in general) are unspecified as far as I know. But given how :visited actually works with selectors/APIs, my take is that without any explicit mention to the contrary, "@scope (:visited) { .a {} }" is allowed (and would match within visited links), but we would report the unvisited situation through CSSOM APIs. In other words, it's privacy-wise equivalent to a ":visited .a" selector. Note: I filed a blocking crbug.com/1452051 to ensure that we don't ship the wrong thing here.

are all links treated as unvisited for the purposes of @scope?

Right, if I remember correctly we did that (in spec) with style queries, e.g. @container style(color:green) would query the "unvisited style". Doing this for @scope would certainly eliminate privacy issues, but it's perhaps a bit drastic if we don't have a specific reason to do it. Instead we can ensure that privacy is maintained in a way that's more consistent with selectors in general, i.e. what I said above.

[slightlyoff via Chromestatus]

LGTM3. If we have a potential `:visited` issue, we should make sure this is shipped with a feature flag for the next few releases. The long term solution for `:visited` is to make it less brittle (a.k.a. "directed visitedness") as we're going to keep adding new combinators that invalidate the assumptions of heuristic approaches.

[Anders Hartvoll Ruud]

On Wed, Jun 7, 2023 at 5:54 PM slightlyoff via Chromestatus <admin+sl...@cr-status.appspotmail.com> wrote:

LGTM3. If we have a potential `:visited` issue, we should make sure this is shipped with a feature flag for the next few releases. The long term solution for `:visited` is to make it less brittle (a.k.a. "directed visitedness") as we're going to keep adding new combinators that invalidate the assumptions of heuristic approaches.

Ack, I filed a reminder to ensure that we have a feature flag.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0000000000008609c705fd8c257a%40google.com.

[nightpool]

Hi all, I realize this is kind of late in the feedback process, but while reading the syntax examples here I found myself pretty confused by the meaning of the "to" keyword. Especially given that the tendency is to read it as the English language sentence "Scope .foo to .bar", it seems to introduce a meaning almost entirely at odds with what it's purpose is (scope the styles TO .foo, EXCLUDING .bar rather than, e.g., "Scope .foo's styles to .bar" or something similar)

Reading the explainer, it sounds like the way this syntax was arrived at was pretty path dependant (building on the previous "from: x to: y" syntax) Has the CSSWG considered any other keyword for this proposal, for example maybe something like 

@scope (.component) excluding (.bar) {

  ...

}

Again, sorry that this feedback is coming so late in the timeline, but curious whether there were any other alternatives explored here. 

And definitely second the opinion on the explainer! I don't think I would have been able to figure out the usage of the "to (...)" clause without it and it really made it clear why it was important and how it fit into the overall design of the feature 

[Carlos Araya]

This is not something that Google can change unilaterally since the feature was specified by the CSS Working Group. 

A better venue for this feedback may be the CSS Working Group Github (https://github.com/w3c/csswg-drafts) . Use [css-cascade-6] in the title of the issue so it'll get to the right people. 

[Masataka Yakura]

On Thursday, June 8, 2023 at 7:40:19 AM UTC+9 nightpool wrote:

Hi all, I realize this is kind of late in the feedback process, but while reading the syntax examples here I found myself pretty confused by the meaning of the "to" keyword. Especially given that the tendency is to read it as the English language sentence "Scope .foo to .bar", it seems to introduce a meaning almost entirely at odds with what it's purpose is (scope the styles TO .foo, EXCLUDING .bar rather than, e.g., "Scope .foo's styles to .bar" or something similar)

Reading the explainer, it sounds like the way this syntax was arrived at was pretty path dependant (building on the previous "from: x to: y" syntax) Has the CSSWG considered any other keyword for this proposal, for example maybe something like 

@scope (.component) excluding (.bar) {

  ...

}

Again, sorry that this feedback is coming so late in the timeline, but curious whether there were any other alternatives explored here. 

There were some discussions about this.

https://github.com/w3c/csswg-drafts/issues/6577

https://github.com/w3c/csswg-drafts/issues/7943#issuecomment-1450516018

They are closed, but you might want to chime in.