Charles Harries

Friday, 10 Feb 2023 8:59 pm

A couple more words on CSS nesting

So nesting has landed in Safari Technology Preview—well done to the WebKit team and hallelujah!

Except CSS nesting feels like a distinctly 2010s approach to writing styles. I've written a little bit about how I feel about CSS nesting before, but I've got a couple more objections:

It unnecessarily couples components. Consider this (hopefully) representative example:

.card {
	box-shadow: 0px 2px 4px rgba(0,0,0,0.15);
	padding: 1rem;
 
	& .image {
		display: block;
		margin: -1rem;
	}
 
	& .content {
		margin-top: 1rem;
	}
}

Why is the style of .image and .content coupled to .card? The .cardelement should be responsible for the display of its children; an .imageshouldn’t care about the context in which it’s displayed. This won’t be the only usage of .image in your stylesheet. Skip the nesting here and keep all of your .image styles co-located and context-agnostic.

.card { box-shadow: 0 2px 4px rgba(0,0,0,0.15); }
.image { display: block; }
.content { padding: 1rem; }

If you do need context-dependent styles, then you’re probably already using something like BEM. Speaking of which: nesting makes it difficult to search for styles in your codebase, especially if you’re using a methodology like BEM.

.card {
	&__image {}
	&__content {}
}

Developers looking for .card__image won’t find what they’re looking for. Prefer instead:

.card {}
.card__image {}

That’s not to say that I’m not going to use nesting. Of course I’m going to use it: more tools in the toolbelt is always nice. But better approaches to tools, and more _selective use of tools, is always going to trump the brute force of numbers.

CSS nesting

Chris Coyier's got me thinking about CSS nesting after posting a short history of the long process of bringing CSS nesting to the browser—starting back in 2006 when Sass introduced it, through requests for comment, editor's drafts, and PostCSS plugins. We've wanted nesting since like forever.

The funny thing is, in 2022, we're moving away from nesting-based approaches to writing CSS.

BEM was the first attempt to move away from nesting-based approaches, moving the nesting from your CSS into your HTML:

/* pre-BEM */
.card .image {}

/* with nesting */
.card {
	& .image {}
}

/* post-BEM */
.card__image {}

Other (slightly more) modern solutions, like CUBE CSS, espouse a total decoupling of components: images shouldn't care about cards, and cards shouldn't care about images:

.card {}
.image {}

And yet other popular utility first-approaches, like TailwindCSS, do away with semantic class names entirely—meaning we don't even need to think about nesting.

(Code snippet left out for, hopefully, obvious reasons.)

By the time we actually get nesting in CSS, people aren't going to need it anymore. I mean, don't get me wrong—there are use cases for it, and I think that developers will find ways to use & abuse it—but it's not something I'm particularly clamoring for.

A Brief and Probably Only Partially Correct History of CSS Nesting, Chris Coyier

Web Code CSS

Posts for CSS

A couple more words on CSS nesting

Further reading

CSS nesting