I’ve written about native CSS nesting before, most recently in March 2021: https://benfrain.com/official-css-nesting-the-last-piece-of-the-puzzle/

More recently I came to write a section on native CSS nesting in the 4th Edition of my ‘Responsive Web Design with HTML5 and CSS’ book, and I’m having to pare it right down.

Subsequently, here I am, in June 2022, spitting out my dummy and jumping up and down because there are still no browser implementations.

I hear about new CSS features on a near daily basis but no-one is making a fuss about nesting, why?

I suspect it’s because of the following reasons:

  • browser vendors don’t rate it as important because they don’t have visibility of the need
  • devs don’t see the need as those that want it, habitually set up tooling to accommodate it

Those are two related but different problems. Let’s dig into the first one, err, first.

Browser vendors don’t see the need

I don’t know how browser vendors could ever get data, beyond anecdotal feedback, that native nesting is needed, nay essential, for modern CSS authoring, so needed sooner rather than later. After all, the browsers never see the authoring style sheets from Sass, PostCSS et al. They only ever receive the yield from these tools which does not betray that much of it was likely authored nested.

I don’t know about you but I suspect a lot of devs use nesting right now. Let’s look at the download stats for Sass on NPM: https://www.npmjs.com/package/sass

As I look at it today, there are 7,740,769 weekly downloads.

B’Jesus! Let’s ponder that a minute.

That is people, more often than not, just setting up a project to use Sass. Just setting it up.

I go weeks without needing to install from NPM and use Sass for nesting every day so this figure is likely just the tip of the iceberg.

And that’s just NPM, a single source of Sass usage, and not even the canonical implementation of Sass, which is actually Dart.

Sass isn’t just about nesting

Granted people will be using Sass for other functionality but since I started with Sass and then PostCSS from 2012 onwards, the most oft used feature is nesting. It is ‘the one’.

Mixins? Once a year. Maybe.

Variables? Not any more, custom properties are better. We have Sass
to thank for that in large part.

Complex Maths, Maps? Once in a blue moon.

Extends? Never.

“It’s the economy nesting, stupid. – Me”

Devs don’t see the need?

Sure, we can carry on with pre-processors and Sass but imagine the
giant pile of tooling many of us can leave behind when we get native nesting? Think of all the projects that get built daily that would no longer need a whole bunch of code just to produce style sheets.

CSS is getting ever more powerful, imagine not even needing a tool to write it as you (likely) do currently?

And then there is the issue of text editors. At present, largely due to nesting, we need to use a special syntax. Sass/scss is the best in this regard as it’s limits are well defined and documented. So we enjoy high quality syntax highlighting there. However, if you are using PostCSS, or something else like some kind of animal, the story is fractured. You can have what you want but good luck with decent syntax highlighting and tooling across all the text editors your team may want to use. I’ll often default to setting up Sass for people, simply because generally, that path will be easier.

99.99% of the time I don’t need anything from Sass other than nesting. You?

With native nesting the story gets far simpler across tools. That’s a lot of developer time saved not setting up tooling!

So come on, stop right now and star these issues and tweet this thing towards anyone with the faintest influence on the features that end up in browsers.