The CSS Reset Contradiction

Published on Dec 19, 2024, filed under development, css (feed). (Share this on Mastodon or Bluesky?)

This article first appeared at SitePoint. It was lightly edited.

Our field (of web and frontend development) has been using resets—which for simplicity here includes “reboots” and “normalizers”—for about 20 years. I say “about” because it seems Tantek Çelik had it all started in 2004 (where you find yours truly, too), but other authors may have used similar techniques even earlier.

Premises

CSS resets are based on three premises:

There are differences in how user agents present web pages, that is, their default styles vary.
These differences have an effect on the given website.
The differences are important to be handled.

It should be obvious to say that if—or once—all user agents handle CSS the same way, there’s no need for a CSS reset.

It should also be obvious that if the differences don’t apply, there’s no need for a CSS reset, either. For example, form styling differences don’t matter on form-less websites.

And—many arguments have unnecessarily broken out over this—it also means that if the differences aren’t considered important enough, there’s also no need for a CSS reset.

I believe that what we’ve seen over the course of the last 20 years is that not all authors have paid attention to whether styling differences across user agents affected them, and whether the differences actually mattered.

But, there are other problems, too.

Reality

For CSS reset users, the reality is that they feel a need to use a CSS reset. It’s possible (and also probable) that there are CSS reset users who don’t feel that way, and either use a CSS reset because they have to or because they feel safer using them. Practically speaking, however, using a CSS reset is part of their reality, too.

What CSS reset users miss is that there’s another reality, namely that of developers and site owners who do not use CSS resets.

This is explicable by the premises outlined earlier, but it’s interesting for two reasons.

That there are sites and apps out there that do not use and that work fine without a CSS reset is pretty much never being talked about in the context of CSS resets.
When we take the extreme positions of always and never needing a CSS reset, positions we observe in practice, then we end up with a contradiction. P & ¬P. ^*

While the premises allow to reconcile the contradiction, the problem persists: In our discourse about CSS resets, no one seems to concede that there are websites that work without resets—something that fundamentally challenges and contradicts the CSS “fundamentalist” notion that they were always needed. That is simply neither true, nor helpful.

Is this all, however? No:

Convenience

CSS resets have become a form of commodity. There are many of them (a search shows more variety than the best collection I could find), and they’re being baked into some HTML/CSS and even JS frameworks.

This makes it easy for developers to forget about the premises, and to assume a general need for CSS resets.

What we could observe long ago, accordingly, is that people stopped questioning their use of resets, even when they may not have an effect. ^†

Consequences

Similar to the effects of shipping invalid and fantasy HTML, all of this is nibbling at the craft of frontend development.

What are our options?

First, we need to be clear about the premises behind CSS resets, and include the premises in our discussions. This will allow for both less heat in the discourse but also better decisions.

Second, we need to do reality checks. There are plenty of sites and apps out there that do not use a CSS reset, and that work completely fine in all user agents. That’s part of our reality, and given the performance and maintenance footprint of some CSS resets, it’s a reality worth paying attention to.

Third, we need to challenge each other and, maybe more importantly, ourselves. Seeking convenience seems natural, and yet it’s important to be clear about the consequences—convenience easily leads to complacency, dogma, and, eventually, ignorance. It’s useful to make our developer lives a little difficult.

When we do all of this, we should get where we could have gotten 20 years ago—to a place where we make very selective use of tailored resets, most likely only in environments of either high technical complexity, or great diversity in developer seniority. But that’s speculation, about a present we don’t have.

The title intentionally left incomplete.

Many thanks to Miriam Suzanne and Jad Joubran for reviewing this post.

^* Personally, I find contradictions fascinating—for example, in formal logic, they allow to conclude anything. But it’s also interesting to humbly challenge them.

^† This is the reason for the lost “first rule of CSS resets”: After having set up a site with a reset, test it at least once without the reset.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), 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. (I value you being critical, interpreting charitably, and giving feedback.)