[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?