CSS Nesting Module
w3.org
w3.org
[0] https://tabatkins.github.io/specs/css-nesting/
The nesting semantics has been a part of SASS/SCSS for the better part of a decade before the proposal, which is now pretty much standard in CSS pre-/post-processing.
It’s been available to use all that time, but AFAIK still requires a build tool. It’s only now becoming a tentative possibility in userland.
When I first saw this link I thought “Hang on a sec., this says ‘First Public Working Draft’, but hasn’t this spec. been around for ages?”
I figured people might make the mistake that this was something new that the W3C were only just getting around to rather than something that has been cooking for a long time.
Didn’t mean to imply that the spec. itself sprang up out of nowhere – it was definitely based on the Sass work that came before it, and you have been able to use this syntax with Sass for a very long time!
@nest looks extremely cool too. An easy way to keep rules affecting one selector logically grouped with it, even if the selector relies on a small thing about its parent elements.
It is worth noting that in SASS you can already refer to parent elements as they have shown with the `@nest` rule (apologies if I misunderstood what you said and you already know this). I do prefer the more verbose `@nest` syntax though, as the intention is clearer.
SASS takes the opposite approach-- there's an implicit `&` at the beginning if you don't specify it elsewhere, and it can appear anywhere (i.e. the example `:not(&)` does not have to have anything like the `@nest` syntax in SASS).
.foo {
color: blue;
.bar {
color: red;
}
}
>Nesting style rules naively inside of other style rules is, unfortunately, ambiguous—the syntax of a selector overlaps with the syntax of a declaration, so an implementation requires unbounded lookahead to tell whether a given bit of text is a declaration or the start of a style rule.
>For example, if a parser starts by seeing color:hover ..., it can’t tell whether that’s the color property (being set to an invalid value...) or a selector for a <color> element. It can’t even rely on looking for valid properties to tell the difference; this would cause parsing to depend on which properties the implementation supported, and could change over time.
>Requiring directly-nested style rules to use nest-prefixed selectors works around this problem—an & can never be part of a declaration, so the parser can immediately tell it’s going to be parsing a selector, and thus a nested style rule.
>Some non-browser implementations of nested rules do not impose this requirement. It is, in most cases, eventually possible to tell properties and selectors apart, but doing so requires unbounded lookahead in the parser; that is, the parser might have to hold onto an unknown amount of content before it can tell which way it’s supposed to be interpreting it. CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS.
I don't care how fast it runs if it doesn't do what I want.
EDIT: yeah, you probably are right ... I know too little about parsers. Maybe there exists a formal proof that you can't make a fast parser for that syntax without unbounded lookahead.
Maybe they should even create CSS from the start as two part system. Convenient syntax for humans, once written compiled to StyleAssembly comfortable for the browser.
Avoiding unbounded lookahead is not "premature" optimisation - if introduced, it would never be possible to remove due to the algorithmic complexity involved.
It is nice not to write too much to get some pseudo elements or selectors working, but that's the extent of it.
Tying your CSS to the markup is a recipe for misery and pain. Over all these years, I've never seen it not turn out to be a nightmare.
There is bunch of CSS features and techniques that work only when you enforce certain parent-child relationships of the CSS rules.
Simplest example of it is 'position:absolute' that requires some parent node to have 'position: relative' to be useful. But there is more to that, both flexbox and grid require certain properties to applied to both parent and children nodes at the same time.
Nesting is one way to enforce those relationships and make sure that they are co-located in the stylesheet code.
Something like that is, in my view, good usage of the nesting:
.parent {
display: flex;
& > .child {
flex: 1 1 auto;
}
}
.child {
color: red
}
In your example, if .child had flex defined internally, then that becomes a bad time in my experience.
What helped was to start building utility classes which I can reuse them.
As the other guy said, nesting selectors has few good usages, should be used carefully.
It’s great for keeping your pseudo-selectors close to your selectors. It’s great for faking scoping, by wrapping a whole file in the whole file in a single classname labelling your component.
But nesting also increases specificity and can distribute the name of a selector token across multiple places within the source file making debugging much harder.
If you use nesting as an aid to writing more CSS faster, you’re using it wrong. If you use it as an aid to constructing what would be a neat CSS file without nesting, then you’re doing it right.
Part of this means that if, say, your language is LL(1) or something like that, you will want to keep future versions of the language LL(1). This can put you in a bit of a tight spot sometimes, when you're making backwards-compatible changes.
If you keep 1-token lookahead, existing CSS parsers can just drop this in.
I guess that's unbounded because the parser can't know how much data it will have to buffer, but in practice we're talking like a few dozen bytes most of the time.
Unfortunately, on mobile I can't quickly find the relevant links.
If the parsing problems are that difficult, I’d rather the @nest be always required.
Pei Y. Wei (wei@sting.berkeley.edu) of ViolaWWW graphical browser:
(BODY fontSize=normal
BGColor=white
FGColor=black
(H1 fontSize=largest
BGColor=red
FGColor=white)
)I'm not sure about that. HTTP2 server push seems to fix this: https://en.wikipedia.org/wiki/HTTP/2_Server_Push
- https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYL...
catThere's even one for mixins! I might have been out of that space for too long.
1: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-column
Would you care about the very legitimate factory processes that made them do it? Or would you instead buy one that didn't?
I'm an end user for SASS and what they are doing for their own reasons is making me want to walk away.
Now, CSS scopes back in the menu when?
https://drafts.csswg.org/css-scoping-2/
Yet another thing Miriam Suzanne has been working on is a proposal for CSS Layers. I think it's a way of declaring what styles should "win" when specificity is equal instead of "last one loaded wins" or using the very crude `!important` tool. This could be particularly helpful if stylesheets for 3rd party components are loaded dynamically or on platforms where the style author doesn't have absolute control over stylesheet order.
https://drafts.csswg.org/css-cascade-5/
All of these will take some time to get right and then some patience for older browsers to die off (or decent fallback strategies, I think all these would be hard to polyfill).
<div style="
> h1 {
font-weight: bold;
}
">
<h1>title</h1>
</div>
And this was hardly the first such discussion. You can find requests going back for years before even that point, with people requesting nesting/hierarchical rules and being shot down.
So no, there was no lack of expertise or passion. So why has it taken this long? A failure of leadership? A failure of process? Perhaps the few, pigheaded opponents of an obviously desired and useful feature were able to sabotage progress by making it impossible to achieve consensus. I don't know. But I refuse to let them off the hook because they finally got around to delivering something in 2021 that the web should have had in 2001.
Passion to make proposals != passion to drive through changes. Making the proposal is the first step. If you're in it for the long haul, you make revisions and get consensus.
Software engineers, largely speaking, love to design things, build them, and move on to the next project instead of dealing with maintenance. Standards committees, largely speaking, are designed to get consensus first and figure out what the issues are with a proposal before implementing it. This kind of "eat your vegetables" way of working drives off a lot of people. And of the remaining engineers who are patient enough to drive something through committee, most of them are off busy doing other things.
You might have a taste of what this is like if you have ever worked at a company that did design docs before implementation. Like, if you're proposing a change to the system, and you write up a short document and get a couple other engineers assigned to review it. Have you ever had more than a couple engineers assigned, like five or ten? All looking at it with critical eyes? Now imagine that they work at different companies.
> Perhaps the few, pigheaded opponents of an obviously desired and useful feature were able to sabotage progress by making it impossible to achieve consensus.
Jeezus, that's a great example of the kind of attitude that makes this so painful in the first place. I want to print this comment out on paper and mail it to the next person who complains about slow standards committees.
You're speculating about how people's personality flaws are sabotaging the process. Well, guess what? You're not the only one doing making shitty comments like that. People who make committees work get a lot of disrespect from random strangers on the internet.
Maybe someday you'll sit on a committee, but you shouldn't have to do that in order to have an ounce of empathy for how standards committees work.
But standards committees display the same depressing insularity and hostility to outside criticism as most institutions, preferring to censure its tone instead of reflecting on its truth. In reality, it wouldn't matter how diplomatically it was conveyed, it wouldn't trigger any kind of self-reflection, just the exact same special-pleading about their task's unique difficulty.
SVG is carried forward by a few determined people against all odds (see e.g. this tale by Amelia Bellamy-Royds https://codepen.io/AmeliaBR/post/me-and-svg)
IIRC the CSS working group is just slow for various reasons (from disinterest to lack of people to drive things forward).
Some parts of working groups and standards committees have been completely taken over by Google that just pushes its own agenda.
And so on.
CSS Custom Properties, on the other hand, I'd argue were much more important to drive through quickly as a build step can't modify them at runtime.