[css-cascade-6] Add ability to scope rules from an imported stylesheet

[faceless2]

This is following on from a brief conversation with @tabatkins at CSSDay.

While I like the scoping proposal, I think it really needs a way to scope styles from an imported stylesheet. As it is now you can define your scopes - great for modularization - but the rules have to be inline in the same sheet, which seems to defeat the purpose a bit to me.

There are several ways to do this - an @import inside a @scope is one, but I think for consistency with cascade layers the syntax should be like

@import uri(module.css) scope(.media-object) to (.content);

Also useful but slightly more controversial (it doesn't have the desired behaviour when the attribute is not recognised) would be adding a scope and (pending a better idea) a scope-to attribute to <link>, the same way that it now has layer (see whatwg/html#7658)

<link rel="stylesheet" href="module.css" scope=".media-object" scope-to=".content">

[tabatkins]

Yeah, this seems reasonable to me. Might quibble a bit on the syntax, but being able to apply a scope to the rules in a stylesheet seems at least as useful as being able to put a stylesheet on a particular cascade layer.

[DarkWiiPlayer]

I think an easier way of handling scope in HTML would simply be:

<link rel="stylesheet" href="module.css" scope=".media-object to .content">

[mirisuzanne]

My proposal would be that both a scope() function in CSS @import, and a scope attribute on the <link> element could accept the full @scope condition syntax:

@scope (.media-object) to (.content) inclusive { … }

@import url(module.css) scope((.media-object) to (.content) inclusive);

<link rel="stylesheet" href="module.css" scope="(.media-object) to (.content) exclusive">

The only edge case that might warrant a special-case is importing a scope with only the scope root. Without any exceptions, that would result in double-parentheses:

@import url(module.css) scope((.media-object));

---

I also want to recognize that adding attributes like this to HTML <link> also requires our proposed (but not yet fully specified or approved) update to the <link media=""> attribute, so that it's possible to test for support of scoping, and only load the linked CSS file if the scoping will be applied. This is also needed for a proposed layer attribute.

There's a PR in progress, but I could use help on some of the details.

[css-meeting-bot]

The CSS Working Group just discussed scoping rules from @import, and agreed to the following:

• RESOLVED: add scope() to @import syntax

The full IRC log of that discussion

<emilio> Topic: scoping rules from @import
<emilio> Github: https://github.com//issues/7348
<emilio> miriam: similar to layer() in @import
<emilio> ... and upcoming layer in <link>
<emilio> ... there's a proposal to add scoping to a sheet when it's scoped
<emilio> ... proposal is to put the scoping condition in @scope
<emilio> ... and put it inside of a function
<emilio> ... so @import "url" scope(<root> to <lower>);
<emilio> ... we might want the same for html
<emilio> ... if you're only using scope you need double parens
<emilio> ... which is a bit ackward
<emilio> ... but proposal is to add the scope() function and maybe a shorthand for that awkward case
<emilio> q+
<heycam> emilio: this feels a bit more similar to @container or such, than @layer
<heycam> ... I feel it's a bit awkward. when would you want to scope a whole style sheet?
<Rossen_> ack emilio
<heycam> miriam: this would be particularly useful for systems that are currently modular / separate style sheets per component
<heycam> ... we could take those separate sheets, apply a scope as importing them
<heycam> emilio: could use shadow DOM
<heycam> miriam: other way is to wrap it in a file
<heycam> emilio: seems like a weird thing to have a shorthand for
<heycam> ... but if you say it's useful
<heycam> emilio: it feels weird in the sense it's depends on the DOM you're styling, rather than layer or media, where it's more about the style sheet itself and the environment
<heycam> miriam: I'll say people are going to do this. they have other methods to do it. I don't feel strongly we need this one, but it will keep coming up
<heycam> ... do we want to provide it as a shorthand?
<heycam> emilio: should we encourage it?
<heycam> ... if you want this kind of scoping for your whole style sheet, you may just want to use shadow DOM and drop the style sheet there
<heycam> miriam: scope is fairly different from shadow DOM
<heycam> ... you could make a fair argument that if the style sheet is meant to be scoped then it should be inside the style sheet
<heycam> ydaniv: it might not be your style sheet
<heycam> emilio: I get wanting to use teh style sheet only when I'm printing, or to put it in this layer, but I want to scope this whole style sheet, since it depends on what selectors you're scoping it to
<heycam> chrishtr: seems like it's the same as @scope
<heycam> ... it's just for a whole file
<heycam> ... that could be convenient
<heycam> ... if we accept the general usefulness of scoping, which I think it is, we should provide primitives to make that easier
<heycam> ... this seems like a natural extension to that
<heycam> emilio: you could make the same argument for container
<heycam> emilio: to me, @scope and @container are more similar than @scope and @media
<heycam> ydaniv: it's more like @layer
<heycam> emilio: do you think so?
<heycam> ... @layer doesn't change whether something matches or not
<heycam> chrishtr: it's scoping to different subtrees
<heycam> emilio: not objecting
<emilio> RESOLVED: add scope() to @import syntax

[bramus]

@mirisuzanne I see that you removed the Needs Edits label a while ago, but there does not seem to be a commit that added text to the spec for this resolution. Could it be this label was removed by mistake?

[mirisuzanne]

@bramus yes that's possible, and seems likely - it accidentally got associated with implicit scope issue.

[romainmenke]

Where would the scope() function be in the syntax of @import relative to supports() ?
I am assuming it will not be placed before layer, so either before or after supports()?

[bramus]

I don’t think the order in which these are declared should matter. E.g. @import url(…) supports(…) scope(…) and @import url(…) scope(…) supports(…) should behave the same, no?

The order in which they are processed could be fixed though, similar to how the individual transform properties are applied in a predetermined order.

[romainmenke]

Currently the order does matter for the existing parts :

1. layer
2. supports()
3. media queries list

Any other order is invalid today.

I agree that a non-fixed order between new import conditions would be good.
Makes it easier for authors to get it right.

---

The order in which they are processed could be fixed though, similar to how the individual transform properties are applied in a predetermined order.

Probably good to specify this, but I don't think it can have observable side-effects if different browsers apply import conditions in different orders. (layer must still be applied at a specific point relative to all the conditions, and this is specified)

The order also isn't specified today for supports() and media query lists : https://drafts.csswg.org/css-cascade-5/#conditional-import

Unless I am overlooking it?

[mirisuzanne]

Do we need to put this back on the agenda to discuss the questions about ordering?

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade-6] Add ability to scope rules from an imported stylesheet, and agreed to the following:

• RESOLVED: allow full reordering of all the current conditions on @import (MQ, scope, ...)
• RESOLVED: the WG recommends having an attribute to enable @scope on the HTML link element

The full IRC log of that discussion

<chrishtr> q+
<fantasai> https://github.com//issues/7348#issuecomment-1719504814
<astearns> ack ydaniv
<fantasai> @import [ <url> | <string> ]
<fantasai> [ layer | layer(<layer-name>) ]?
<fantasai> [ supports( [ <supports-condition> | <declaration> ] ) ]?
<fantasai> <media-query-list>? ;
<matthieud> fantasai: currently the order of trailing condition in @import is fixed
<astearns> ack chrishtr
<lea> +1 this seems pretty straightforward
<matthieud> fantasai: we resolved to adding @scope on @import already
<lea> more generally on this issue, I wish it were possible to simply nest @import in @scope rather than need to learn new syntax
<astearns> ack dbaron
<matthieud> dbaron: it seems that talking about reordering some of them are self explicit and media queries which are less isolated
<matthieud> dbaron: we have 2 options : allow reordering everything but the MQ part ; or even across the MQ
<matthieud> fantasai: no strong opinion
<matthieud> fantasai: but no technical issue with reordering everything
<matthieud> astearns: could we allow full reordering and open a following issue if there is an actual problem ?
<matthieud> dbaron: it's not a technical issue, but maybe it's gonna be more confusing for author
<matthieud> PROPOSED RESOLUTION: allow full reordering of all the current conditions on @import (MQ, scope, ...)
<matthieud> RESOLVED: allow full reordering of all the current conditions on @import (MQ, scope, ...)
<matthieud> chrishtr: we should also add scope condition on HTML link element
<matthieud> miriam: the proposal is adding a scope attribute which take the scope-prelude as argument ?
<matthieud> fantasai: new attribute specifically for scope or a generic attribute for condition ?
<fantasai> s/condition/parameters
<matthieud> miriam: there has been an issue in WHATWG about @layer should have its own attribute or not
<matthieud> miriam: whatever the answer, we should do the same for @scope
<bramus> https://github.com/whatwg/html/issues/7540 is the issue
<matthieud> PROPOSED RESOLUTION: the WG recommends having an attribute to enable @scope on the HTML link element
<matthieud> RESOLVED: the WG recommends having an attribute to enable @scope on the HTML link element
<futhark> present-

[romainmenke]

Can we make it so that authors do not have to wrap simple scope conditions in extra parenthesis?

@imports "foo" scope(.foo); /* -> authors will want to write this */
@imports "foo" scope((.foo)); /* explicitly wrapped in parenthesis */
@imports "foo" scope((.foo) to (.bar));

[romainmenke]

allow full reordering of all the current conditions on @import (MQ, scope, ...)

There is an issue with allowing any order.
Media query lists can be partially valid.

Any media query list with more than one media query would swallow unrecognized trailing parts.

@import url("foo") screen, print something-invalid(really-does-not-exist);

This still applies fine everywhere that matches screen.
The same for:

@import url("foo") screen, print scope(.foo);

You can see this in action in this codepen:

https://codepen.io/romainmenke/pen/WNVvyBY

---

Can we instead just allow any order between new conditions?

• layer always first
• media query lists always last
• anything in between can go in any order

---

Edit: it seems this problem already exists today even without allowing any order:

@import url("foo") scope(.foo) print, screen; /* "foo" is applied, even in browsers without support for `scope` conditions */

Updated example showing that unknown conditions are just ignored both before and after media query lists: https://codepen.io/romainmenke/pen/QWebVmp

So maybe this is fine?

[DarkWiiPlayer]

If I remember correctly, @scope { /* styles */ } to mean "scope to the parent of the style tag" is still a thing, would <link scope src="whatever"> work analogously then? That seems like something that could be convenient in practice.

[mirisuzanne]

@DarkWiiPlayer I agree that could be useful. We didn't clearly specify how it should work here, so probably should work through those details.

@romainmenke oh that's interesting.