Thoughts on CSS in 2024

Published on July 15, 2024 (↻ July 29, 2024), filed under Development (RSS feed for all categories).

I haven’t written about CSS in a while 😬 (Instead, a new book about HTML optimization, some comments about veganism, and other random things.) Am I still alive? Yes! 👋 (You can feel my heartbeat over at Frontend Dogma!)

So what are these thoughts, about CSS, in 2024? Let me keep it light and casual.

What I Appreciate

There are a few things I appreciate. These things aren’t necessarily what everyone else may be hyped up about—though they don’t exactly go unnoticed, either.

What I appreciate deeply, given how long and how much I’ve missed that power, are all 86 ^* of today’s selectors. (I’ve explained a little in CSS: :has() and the Lost Paradigm.)

If you had me pick three selectors I particularly appreciate, I’d choose :has(), :not(), and is:() (over :where(), because I usually like the added specificity).

Sure, there are other things I appreciate, like grid or container queries, but the reason why I’m so selector-focused is that selectors have a direct impact on HTML code quality. ^† What’s in a style sheet is far less important than how the HTML looks like—with separation of concerns, we can swap that out in an instant. (You know all of this, but this is such a misunderstood biggie, I have to hold myself back here!)

Favorites

I have some favorites, too.

I’ve found myself to set scroll-behavior: smooth in most every new project. (It made quite a difference on the World’s Highest/Longest Website!)

I really like text-wrap: pretty, which had me dial down on the hyphens property and which obsoleted both tooling and habits around fine-tuning typography by setting no-break spaces.

It’s old, but I also like ::selection, which should—could—probably be used by more websites and apps.

There are a few things I’m monitoring, like ::target-text, but that’s not there yet.

That list may seem short, but there’s surely a reason for this: Other “bread and butter” properties and declarations are even older, and don’t feel like favorites because of their ubiquity. Yet others are so individual, i.e., project-specific, that I couldn’t call them favorites, either.

What I Don’t Need

There’s a lot that I don’t need from contemporary CSS.

Though not a “feature” of CSS, I don’t use resets, and never have. As I’ve written about resets in the past, I won’t do so now. One angle that I haven’t played in the past, however, is to ask how we could have any projects without resets (which exist), if resets are so critical. I don’t think this point has ever been appreciated by reset proponents.

I don’t use logical properties (except for axis shorthands, like margin-block). I’ve written about logical properties, too. Having worked on bi-directional projects, I know about their value (if I worked on any such project now, I’d absolutely use logical properties)—but experience working on international sites is what makes me be clear about when they’re not needed. (There’s more here, sure, but this point of need also lacks appreciation.)

I use custom properties, but rarely. They’ve proven their value, but that value is limited when keeping style sheets DRY. Using declarations just once works. I know the field rushed past this, but boy, it does this all the time (hi Conditional Comments, AMP, and yes, resets).

There are more things I don’t need and use, but well, that’s the beauty of web development—we don’t have to use it all. (It’s good to keep an eye on what’s becoming available though.)

❧ This must be a somewhat strange look at CSS, in 2024. And yet, covering CSS pretty much all the time, I know this also adds perspective. Selectors could use more recognition. Favorites differ wildly. And we usually seem to write about what we need and want, not what we don’t need and want. (If you are explicit about your not-needs, email me so that I feature your perspective on Frontend Dogma!)

^* That’s the number I have in my upcoming book, to learn-by-memorizing (yes!) HTML and CSS!

^† This needs explanation insofar as the range of impact goes from dictating HTML attributes (like classes), values (like class names), and even structure (like styling-related containers) to not affecting the HTML markup at all. Quality-wise, this then maps to potentially highly negatively impacting HTML quality (increased payload, decreased maintainability) to not impacting it at all (the highest level).

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)