While I like the dot notation because it's commonly used in programming languages, I think it might make more sense within the context of CSS to use a space:

• it matches how we write descendant selectors, which is the closest concept we have.
• it doesn't match how we write class selectors, which are a flat concept, not a nested one

On the other hand, staying away from the Selectors analogy might be a good thing? In particular, this shouldn't match the descendant combinator, but rather the child combinator. So instead leaning on the programming-language . actually feels a little better to me.

(And I don't want to use > and admit the possibility of a descendant combinator as well; that seems unnecessary.)

Just thinking out loud, considering separators that haven't been mentioned yet:

• another typical css separator is the comma, but it implies a flat list, not a hierarchy
• a rarer css separator is the slash. In the context of css, it doesn't imply a hierarchy either, but in file paths or URLs is does

Overall, I think I'd still go with the space, not because it matches selectors, but because it's the simplest thing used all over the pace in CSS as a separator. The period feels a bit foreign. But I wouldn't push back much if people insisted that we should go with that.

Worth noting that this syntax can also be used inside a (currently comma-separated) list of layers. To show a few of those options:

@layer framework.default, framework.theme;
@layer framework default, framework theme;
@layer framework / default, framework / theme;

Or in the block syntax:

@layer framework.theme {
	blockquote { color: rebeccapurple; }
}

@layer framework theme {
	blockquote { color: rebeccapurple; }
}

@layer framework / theme {
	blockquote { color: rebeccapurple; }
}

I think the space works well in both cases, and adding punctuation feels unnecessary.

The CSS Working Group just discussed [css-cascade] What is the appropriate syntax for appending to nested layers?.

If we did use the /, I'd expect it to have the same "no spaces around" restriction as period - @layer framework/theme {} - to properly invoke the filepath analogy.

But the discussion seems to have landed us on a choice between just period and space, with a mild preference in the IRC straw poll towards period. We're keeping this open for further discussion, but if nothing else comes, I guess we'll stick with the period that's currently in the spec.

Stating my arguments from the meeting a little more explicitly:

• Using space-separation to indicate hierarchy occurs (I think) nowhere in CSS values (only in Selectors; see next point). In almost every instance, space-separated values don't even imply an ordering; they're almost always re-orderable. (color-scheme is the first exception that comes to mind where order does matter.)

• Space-separation is used in Selectors, where it represents the descendant combinator. But if Selectors are the analogy we're going for here, then the descendant combinator is the wrong combinator to use - it implies an arbitrary amount of separation between the items on either side. We'd want the child combinator > to invoke the correct analogy.

• But relying on a Selector analogy is a little fraught, anyway.

  • First, it reuses the visual metaphor of something that lives in the same conceptual space, and very similar syntactic space - Selectors are already there, but these are not Selectors, and I don't think it's great to have them be so visually confusable.
  • Second, it's a broken analogy. These don't work like Selectors in any other way than referencing a hierarchy. The "nodes" don't have any qualities besides their name (and I don't expect us to ever want to add anything else to them), and you can't link them with any other combinator - no descendants, no siblings. When you draw on a metaphor you'll rarely get a perfect match, but if you only match in the one aspect and nothing else, it often causes more confusion than it resolves.

• Using the period instead leans on the metaphor of nested objects, using syntax common to most languages invented in the past half-century (especially when weighted toward languages webdevs are likely to know, notably JS).

  It does collide with Selector syntax as well (a compound selector with a type selector and multiple class selectors), but we're purposely not drawing on that metaphor; this is a separator, not an identifying prefix.

And carrying over a detail from florian's comment in IRC, I expect us to impose a "no whitespace" restriction around the period: foo.bar is good, foo . bar is invalid.

Regarding commas; now that I can safely use comma-less color functions in CSS [1], commas read as fallbacks, consistent now too with my experience in color() and var(). The idea of it being a fallback may even be written into a spec somewhere.

Regarding forward slashes, I have read those as separators, which is how they are used in color functions and grid.

Therefore, I would interpret @layer framework / default, framework / theme to mean "the layers 'framework' and 'default', or (as a fallback?) the layers 'framework' and 'theme'".

1: An example of a comma-less color function would be rgb(102 51 153). This also the syntax automatically generated in Chrome devtools when adjusting the color system)

EDIT: I pasted the wrote rgb() function. It’s fixed.

The idea of it being a fallback may even be written into a spec somewhere.

The general policy is that commas are used to separate lists of parallel syntax. Those might be for fallback, but they're also used for stacked things (like background), consecutive things (like gradient stops), or just a group of things (like Selectors).

I'm under the impression that the syntax has settled on using the . as a separator and that this issue can be closed, no?

The fact that it can occur before a curly brace block makes it feel more akin to selectors to me, so I'm not that opposed to > to show the hierarchical relationship. @page is selector-like, with its pseudo-classes.

@layer framework>default

But I can see I'm in a minority there, and I'm not super attached to that either.

When I look at other at-rules, I see relationships denoted by colons, as in @supports and @media, which doesn't seem right here, and conjunctions in @media. Conjunctions still aren't what we want, but what about another small word, such as a preposition?

@layer default of framework

Agenda+ to resolve this before browsers release the feature

The CSS Working Group just discussed What is the appropriate syntax for appending to nested layers?, and agreed to the following:

• RESOLVED: Leave the spec unchanged with dot syntax