[css-cascade-6] Support @import scope() syntax

[andruud]

#7348

[andruud]

Note that this PR has two commits. The first commit copies over the @import section from level 5, verbatim.

[cdoublev]

- [ scope( [ (<<scope-start>>) ]? [ to (<<scope-end>>) ]? | <<scope-start>> ) ]
+ [ scope( [ [ (<<scope-start>>) ]? [ to (<<scope-end>>) ]? ]! | <<scope-start>> ) ]

(do not allow empty alternative)

[andruud]

But @import scope() is valid, though. It gives you an "implicit scope", i.e. equivalent to @scope { }.

[cdoublev]

Ok, that is intentional then. Sorry! =)

[romainmenke]

Shouldn't this then be @import scope in parallel with @import layer?

I'd rather not have authors needing to remember:

valid	invalid
@import layer	@import layer()
@import scope()	@import scope

[andruud]

@romainmenke Ah, yes, that's seems better.

[cdoublev]

Is it possible to edit Cascade 4 and 5 to prevent w3c/reffy from extracting <import-conditions>, which would be removed by this PR in Cascade 6?

- @import [ <url> | <string> ] ... <import-conditions> ;
- <import-conditions> = [ supports( [ <supports-condition> | <declaration> ] ) ]? <media-query-list>?
+ @import [ <url> | <string> ] ... [ supports( [ <supports-condition> | <declaration> ] ) ]? <media-query-list>? ;

---

Is it possible to define <supports()> and <media()> in Conditional 5, and <scope()> in Cascade 6, to avoid duplicate/overlapping definitions?

For example, supports() is defined differently in CSS Values 5, Conditional 5, Cascade 4/5.

<supports()>, <media()>, <media-query-list>, would define the import conditions.

@import [ <url> | <string> ]
        [[ layer | layer(<layer-name>) ] || <scope()> || <supports()> || <media()>]?
        <media-query-list> ;

<scope()> = scope( [ <scope-selector> | <scope-start> ]? )
<supports()> = supports( [ <supports-condition> | <declaration> ] )
<media()> = media( <media-query-list> )

Note: <media-query-list> does not need ? as it implicitly accepts an empty list.

<scope-selector> would be defined below the definition of @scope with @scope <scope-selector>? { ... }.

At least, the grouping brackets no longer seem necessary around scope(), now that it is implicitly optional.

[andruud]

@cdoublev That does sound quite reasonable, but I'll wait for an editor to have an opinion on what this should look like.

<media()> would be spec'ed later / separately, since we don't have a resolution to add it yet.

---

Trying another editor, since @mirisuzanne is unresponsive.

[mirisuzanne]

I agree with the proposed change from Romain, and left a couple other notes. Overall it looks good.

[mirisuzanne]

Need layer-empty added to the oldids on line 46, or this PR doesn't build

[mirisuzanne]

I see the reasoning behind this, and think it's probably the best behavior - but it is a departure from @scope. I image we would also apply this behavior to any html scope attribute, so those would be consistent. Is it something that deserves it's own discussion?

[romainmenke]

Is it correct that wrapping an entire stylesheet's contents with @scope would behave differently from importing that same stylesheet with a scope() condition?

I am unsure if that is the best option.
I think it would be surprising to authors as they would assume this to be purely a syntactic difference.

If the behavior is different it also implies that bundling becomes impossible, which might make the entire feature unusable in practice as it would force CSS authors to serve unbundled stylesheets and take the associated performance hit.

[mirisuzanne]

Fair points. It sounds like this does in fact deserve it's own issue. :)

[andruud]

I see the reasoning behind this

I'm not sure I do (anymore). I remember concluding that anything else was impossible, but I don't remember why.

We'd have to allow relative selectors top-level, but we could do that and spec that they are relative against :scope.

(Re-interpreting & is deeply incompatible with Blink's implementation of nesting, but we don't have to let that guide the discussion.)

[mirisuzanne]

<import-conditions> were given their own construction for the sake of reference from an HTML attribute, although I don't think that proposal is moving forward anymore.