Repository navigation
[css-cascade] What is the appropriate syntax for appending to nested layers? #5791
Description
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.
Activity
fantasai commentedon Jan 9, 2021
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:
tabatkins commentedon Jan 9, 2021
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 commentedon Jan 10, 2021
Just thinking out loud, considering separators that haven't been mentioned yet:
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 commentedon Jan 27, 2021
Worth noting that this syntax can also be used inside a (currently comma-separated) list of layers. To show a few of those options:
Or in the block syntax:
I think the space works well in both cases, and adding punctuation feels unnecessary.
css-meeting-bot commentedon Jan 27, 2021
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 commentedon Jan 27, 2021
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 commentedon Jan 27, 2021
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-schemeis 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.
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.baris good,foo . baris invalid.jonathantneal commentedon Jan 27, 2021
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()andvar(). 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 / themeto 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 commentedon Jan 28, 2021
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 commentedon Sep 10, 2021
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 commentedon Sep 13, 2021
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.@pageis selector-like, with its pseudo-classes.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
@supportsand@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?mirisuzanne commentedon Sep 21, 2021
Agenda+ to resolve this before browsers release the feature
css-meeting-bot commentedon Oct 6, 2021
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 syntaxThe full IRC log of that discussion
<dael> Topic: What is the appropriate syntax for appending to nested layers?<dael> github: https://github.com//issues/5791
<dael> miriam: Allow to nest and then concat names and allow you to access. If you put theme inside framework you gat frameworktheme layer. What is syntax?
<dael> miriam: In spec we have dot between two. Other options are space or other divider.
<TabAtkins> @layer framework { @layer theme {...}} -> appendable via @layer framework.theme {...} in current spec
<dael> miriam: We have this behind a flag in browsers. Change before we release or is it okay?
<dael> astearns: Anyone with concerns about dot syntax?
<dael> astearns: Silence.
<dael> astearns: Prop: Leave the spec unchanged
<dael> astearns: Obj?
<dael> RESOLVED: Leave the spec unchanged with dot syntax
<fantasai> I used to be more in favor of spaces (but not strongly) but thinking about how we might need to extend the syntax, I think the dot syntax is better.