[css-cascade] What is the appropriate syntax for appending to nested layers?

[mirisuzanne]

The draft Cascade 5 specification allows nesting cascade layers, and appending styles to nested layers using a dot (. period/full-stop/U+002E) character:

@layer framework {
	@layer default {
		p { margin-block: 0.75em; }
	}

	@layer theme {
		p { color: #222; }
	}
}

/* These styles will be added to the theme layer inside the framework layer */
@layer framework.theme {
	blockquote { color: rebeccapurple; }
}

It might also work to use a space, or some other character in place of the dot.

[fantasai]

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

[tabatkins]

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.)

[frivoal]

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.

[mirisuzanne]

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.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: [css-cascade] What is the appropriate syntax for appending to nested layers?
<dael> github: https://github.com//issues/5791
<dael> miriam: In the layers spec we allow nesting of layers. Accessing nested layers through some syntax to say I'm not jsut adjusting default but defualt inside framework. What is syntax to combine
<dael> miriam: In spec we use a dot. framework.default framework.theme. Felt to some of us space is fine and more css-y
<dael> miriam: At the bottom I provided samples of proposals. / syntax. , syntax but we have that elsewhere for ordering.
<TabAtkins> q+
<fantasai> +1 to space
<dael> miriam: I think space is simpliest and communicates fine
<astearns> +1 to space, too
<leaverou> yeah avoid commas
<leaverou> ^ that was ChrisL
<dael> TabAtkins: I would be fine with space. But every time I look at this the dot looks really good. Probably my JS mind, but want to lean on it. Implies the nesting in a way the space doesn't
<dael> TabAtkins: Okay with space, but I really like the period
<dael> florian: One reason I'm not too hot on period is b/c this is new syntax I start to wonder if you can have spaces around period or css comments betwee. I suspect answer is yes and then it starts to drift from feels like JS
<dael> TabAtkins: I would say no spaces. Can't stop comments, but no space
<dael> fantasai: I agree with florian. B/c we don't have existing syntax this gets complicated. In terms of convaying nesting we doo it with a space in selectors
<TabAtkins> q+
<leaverou> q?
<dael> leaverou: Agree a space is more natural to css
<JonathanNeal> Strong agreement with the comment about periods. In CSS, a space can mean I’m configuring something, adding another value, and rarely does it mean I’m reaching into something.
<astearns> ack TabAtkins
<dael> TabAtkins: Analogy with selectors is why I'm uncomfortable with space. The direct nesting is the arrow and I don't want to do that.
<JonathanNeal> Oh, right, except for selector syntaxes, and I would not want to mentally parse the space as a kind of combinator.
<dael> TabAtkins: We don't want to imply other selecto syntax works. It's a bit foreign to css but similar to many other programming languages. Method chaining works exactly how we want. Dealing with space as combinator is only kinda sorta appropraite
<fantasai> yeah -1 to using >
<dael> astearns: Looks like TabAtkins and JonathanNeal like period. Everyone else has said space. Anyone else with period preference?
<dael> astearns: TabAtkins you said you would be okay using space? You wouldn't object?
<dael> TabAtkins: I won't object but I may want to revisit. Selectors is only place we use space to do nesting and that's not the right type of nesting to evoke. Not happy, but won't object
<JonathanNeal> In CSS, I prefer when space is just the absence of meaning.
<dael> fremy: one question. if we want to do search isn't using space a bit harder. Less searchable. If you use space you split the things apart. If you want ot use in properties it's more difficult
<TabAtkins> quick straw poll?
<dael> fremy: Not a strong preference, but I think dot is a bit nices. Easier to search with a dot then with a space.
<dael> astearns: You mena searching for all nested layers?
<dael> fremy: Yeah.
<dael> fremy: In general I feel it's more unique to space. Not a strong opinion. I feel like dot is more useful.
<dael> leaverou: How about straw poll.
<leaverou> space
<TabAtkins> Period
<fantasai> space
<jensimmons> space
<dael> astearns: IRC straw poll.
<futhark> period
<faceless2> period
<JonathanNeal> period
<argyle> period
<dholbert> period
<fremy> period
<florian> space
<bradk> Period
<dlibby> period
<rachelandrew> space
<dael> astearns: From that it looks like we're learning toward period
<dael> astearns: 8 to 6
<dael> leaverou: Not exactly consensus
<dael> TabAtkins: 9 to 5 I think. Not consensus. But changing to less popular might be premature.
<dael> astearns: Spec uses dot?
<dael> many: yeah
<dael> fantasai: Then we'd have to put in work to make periods work.
<JonathanNeal> Not that it should matter, but syntactically, I think a period is easier than a space.
<argyle> https://www.irccloud.com/pastebin/fbQB8Xeq/
<dael> florian: Agree it's more awkward to spec, but that's not the main concern
<dael> astearns: No consensus. Leave this one open and leave spec as is for now?
<dael> fantasai: Leave issue open and collect feedback
<dael> astearns: Nice to close issues, but I don't think we have consensus. We're down to space or period, though

[tabatkins]

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.

[tabatkins]

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.

[jonathantneal]

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.

[tabatkins]

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).

[bramus]

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

[bradkemper]

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