CSS Nesting Module

[JimDabell]

It’s not apparent from the document posted, but this is actually almost six years old [0] and already implemented as a PostCSS plugin for just as long [1]. It was adopted by the CSS Working Group a couple of years ago [2]. So this is very well-established and you’ve been able to use this syntax for many years. But it’s good to see it moving forward and hopefully browsers will implement it soon now.

[0] https://tabatkins.github.io/specs/css-nesting/

[1] https://github.com/csstools/postcss-nesting

[2] https://github.com/w3c/csswg-drafts/pull/2878

[eyelidlessness]

This is good historical context but missing one bit and another deserves clarification.

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.

[TheRealPomax]

And proposed a decade ago (https://lists.w3.org/Archives/Public/www-style/2011Jun/0022....)

[akersten]

This looks awesome. I'm so glad they re-used the & syntax popular in many compile-to-CSS languages. Between this and CSS variables, I might not even need SASS in my toolchain anymore, which would be amazing.

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

[Ciantic]

Was thinking about SCSS/LESS too, but notice that this is not valid:

    .foo {
        color: blue;
        .bar {
            color: red;
        }
    }

The ampersand is required, unlike in LESS and SASS. I don't yet understand why, because requiring ampersand makes copy pasting things difficult, as you need to add or remove seemingly redundant ampersands to move in out of nesting.

[honie]

Those were my reactions, too! The one thing that I want the most whenever I have to jump out of the CSS per-processor world and write regular CSS.

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.

[leemcd56]

I agree! I may use Sass if I were to write functions to generate grids, or element permutations based on a color palette, but at this point I don’t feel it’s all that needed.

[gherkinnn]

I fail to understand people's infatuation with CSS nesting.

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.

[roman-holovin]

I feel that problem is that some CSS has to be tied to markup and some of it - doesn't.

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
   }

I specifically added an example that changes color for class `child` and I think this should not be included in the nested rule because this part of the styling is not affected by a parent in any meaningful way.

[psilo]

Totally agree with you. Nesting selectors increase coupling with DOM. I did this a lot and I was not productive. At first seems to reduce code, but them, every change in the template I needed to change in the CSS.

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.

[wildrhythms]

I started using Tailwind and couldn't agree more. Everything nowadays seems to be deeply nested and closely tied to a component. Most large React apps have a strict 1 component <-> 1 CSS file relationship. Try deciphering how your styles are being inherited to a component through a maze of nested components and their independent CSS files: nightmare.

[gedy]

Nice, nesting seems to be so much more understandable for typical developers, will be nice to not need SASS or LESS preprocessors just for this.

[schube]

While as part of SASS nesting is a marvelous feature I am an absolute fan of, I can’t help but see this as yet another step in the direction of making new and varied browsers even more impossible to implement. I rather like the “unixy” route of having SASS handle the complexity of understanding nesting and having a simpler browser consume plain flat CSS.

[gherkinnn]

That ship has long sailed. Nesting is inconsequential at this point.

[the_other]

Nesting is useful, but not as useful as you think.

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.

[ihuman]

I read the page's reasoning for why everything can't be directly nested, but I still don't get it. Why is an "unbounded lookahead" an issue?

[klodolph]

The amount of lookahead necessary dictates what algorithms you can use for parsing. If you go from 1-token lookahead to unbounded lookahead, you might force a lot of people to rewrite their parsers or make major changes (because they would have to use different algorithms). This would mean that a lot of CSS parser would simply not adopt the new syntax, at least not in a timely fashion.

If you keep 1-token lookahead, existing CSS parsers can just drop this in.

[wlib]

Keeping a tiny bounded lookahead is essential for the extremely fast and memory-efficient parsing that browsers want for CSS. Sass, less, &c. don't really have to care about that, and they have the benefit of also being able to completely trust that the user won't give pathological inputs - unlike browsers on the web. Also, I think the standards bodies want to minimize their changes in general, to keep the door open for unexpected changes later.

[zeroimpl]

The term "unbounded" seems a bit strange to me too. At worst you only need to lookahead until the next ; or { to figure out if it's a property or a nested selector.

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.

[eyelidlessness]

It’s the same reason backtracking is a performance hit in any scenario. CSS is blocking, and if a selector needs to wait for every network resolution and JS parse/execution to resolve it’s essentially as expensive as your worst case scenario.

[rasz]

This looks familiar, pre CSS 1993 familiar in fact http://1997.webhistory.org/www.lists/www-talk.1993q4/0264.ht... https://eager.io/blog/the-languages-which-almost-were-css/

Pei Y. Wei ([email protected]) of ViolaWWW graphical browser:

    (BODY fontSize=normal
          BGColor=white
          FGColor=black
      (H1   fontSize=largest
            BGColor=red
            FGColor=white)
    )

[cosmotic]

This seems nice but we'll still likely need preprocessors to aggregate multiple files. The import feature of CSS results in additional, serial requests, which are very not good.

[eyelidlessness]

This is where standards and bundlers are converging. Move as much syntax to standards as possible to relieve compilers of the duty, use bundlers to do static analysis of dependencies and build optimal packages for the network waterfall.

[inopinatus]

sometimes your preprocessor is

    cat

[TheRealPomax]

unless you send different files each request, pretty sure browser caching is still a thing and imports with `preload` links are just fine?

[spankalee]

We rally need Web Bundles so we don't have to merge files, but can create a bundle with all the individual files in it that populate the network cache correctly.

[simlevesque]

> The import feature of CSS results in additional, serial requests, which are very not good.

I'm not sure about that. HTTP2 server push seems to fix this: https://en.wikipedia.org/wiki/HTTP/2_Server_Push

[otrahuevada]

Between this and SASS starting to add awkward rules like deprecating "/" for division and stuff, it's finally time for me to start pushing internally for PostCSS + plugins.

There's even one for mixins! I might have been out of that space for too long.

[mvolfik]

Sass didn't deprecate `/` for division for their own giggles - it's because `/` is increasingly being used in plain CSS values (most prominent example I can think of now is css grid[1]), so it became increasingly hard to distinguish raw values from Sass expressions

1: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-column

[southerntofu]

WTF. Why is w3.org blocking tor exit nodes? That's a recent and worrying development!

[thepra]

Hell YES, I've been using SCSS for this reason only, just to have a CSS codebase that didn't need repetition and nesting provided more documentation by default(given that there's a hierarchy in place)

[22c]

I used SASS in a recent project essentially just for this feature, so it seems like the CSS WG is slowly chipping away at convenience features that some people have been using for quite some time.

[throw_m239339]

Good!

Now, CSS scopes back in the menu when?

[extra88]

There's work CSS scoping going on as well.

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

[samwillis]

I would love to see this implemented within the style attribute in html, it would create a nice middle ground between totally separate css files and the new trend of designing with phudo-css class names with tools like Tailwind. It keeps your css close to the semantic html without drowning it in style and class attributes. So you could do something like this (clearly pointless) example:

  <div style="
    > h1 {
      font-weight: bold;
    }
  ">
    <h1>title</h1>
  </div>

Just add a way to inherit from a css class within the style attribute and you have a sort of inline sass.

[no_way]

Inline styles defeat very large part of browser optimizations, so it is very unlikely something like this would be added.

[paulclinger]

The very last example in 2.1 ("__bar.foo { color: red; }") should instead be "foo.__bar { color: red; }" if I understand it correctly.

[tantanel]

No, I think the example is correct. __bar in this case is interpreted as an element name (custom html element), not a class.

[stupidcar]

Good. But nesting could and should have been added to CSS a decade ago or more, and it is an abject failure of the working group that it wasn’t, despite the obvious, overwhelming demand from authors.

[dbbk]

Considering it works just fine with a build step it's not that urgent.

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.

[klodolph]

"Abject failure" is more than harsh. Not many people have the expertise to sit on these committees and the passion to drive through new changes. It takes a while.

[emadabdulrahim]

It's definitely way overdue. I hope this gets in soon and full modern browsers support.