Published on Apr 6, 2026, filed under development, css. (Share this post, e.g., on Mastodon or on Bluesky.)
This article was first published on SitePoint.
Putting aside invalid code, can you write “wrong” CSS?
You regularly find someone who argues yes, by either saying what you have to do or by saying what you must not do.
For example, peers have argued to use resets, not to use !important, not to use shorthands, not to use certain selectors, only to use logical properties, &c.
Others have suggested that you cannot write “wrong CSS.” Personally, for the examples given, I have.
Why can’t you write wrong CSS?
I submit four reasons. (Comment on the socials if you believe there are more—or that I err!)
Contents
- If It Works, It Works
- The One Who Suffers Is You
- It’s Easy to Change
- Barriers for Users Are a Web Platform Responsibility
- But What if Someone Still Says Your CSS Is Wrong?
1. If It Works, It Works
If there’s no clear practical disadvantage to it—like significantly worse UX or concretely experienced worse DX—, there’s no reason to change something that’s working. CSS is not occupational therapy.
Furthermore, the web platform rarely if ever deprecates anything, and instead emphasizes backwards-compatibility. This means that the code is safe. As Mark Pilgrim once said:
Standards are like sex; one mistake, and you’re stuck supporting it forever!
There is no wrong CSS here.
2. The One Who Suffers Is You
Let’s assume there’s something extraordinarily bad in the CSS. For example, your organization is opening up to the Arab world and all websites need to support RTL scripts.
That is your problem, not anyone’s who promotes the use of logical properties.
It is your problem, your incentive to solve it, and your call when to do what in your CSS. Therefore, there is no wrong CSS here, either.
3. It’s Easy to Change
Now your site uses an old layout technique—say, float-based—, and eventually you dislike this way of doing layout.
But since we’re talking about CSS—not presentational HTML—, you can change this easily. “Easily” as in making the necessary changes (depending on the project, tests may not be run and updated so quickly, but this is a different topic).
So should there be an actual need for a change, where one solution is noticeably better than another, the change can always be made.
It’s hard to argue there is wrong in CSS if CSS allows to quickly pivot and change solution, in a sense that it can’t be a grave mistake, one that’s hard to correct. We already know that it’s most important to get the HTML right.
4. Barriers for Users Are a Web Platform Responsibility
Caution: We’re not there yet. Think of this as a perspective we could push a lot harder on.
Assuming the case that there’s something entirely wrong, and the CSS you’re using is creating problems for your users.
While this can prompt action—nothing here says you may not act—, here’s where we can fall back to a point not often appreciated:
The platform should make it hard to create barriers, and easy to remove them.
This isn’t an official design principle in our standards and their implementation—but it’s certainly one we could adopt.
But what is this saying?
It’s saying in general terms what Joe Clark, for example, has said in more specific terms (“if a browser or adaptive technology can or should handle an accessibility issue, I won’t”):
The developer provides the intent; the platform provides the guarantee of access.
This means that when there’s a CSS problem so big that someone would say your CSS is wrong—it might be something that should be addressed on a platform level.
Stay with me here: As quoting Joe may indicate, we’ve been here before, when issues were dealt with by developers that really should have been handled elsewhere. Just one more example? The “notch,” where solutions were proposed to solve a problem which we as developers should probably not need to solve (yet whose not-solving could easily be dubbed “wrong”).
More interesting may be a simplified extreme case: Imagine someone using black text on a black background. Inaccessible (and nonsensical). What this point suggests is that even that would not be wrong CSS—but that the ability to remove such barriers is a platform responsibility. That could happen in various forms: By user styles as we already have them, by automated color correction, or by some mode a user could toggle to access the content.
Let me know if this could be useful to dissect further, and I’ll try to go over this topic in a separate article.
But What if Someone Still Says Your CSS Is Wrong?
Then first, check on the context and if it applies to you. For example, if you’re joining a team working on an international website supporting multiple scripts, you may be asked to use logical properties. That is sound. That is fine.
So if the context applies to you, then consider the advice.
If it doesn’t, then you’re still free to accept it, but that’s your choice.
Context is going to tell you if you’re dealing with advice—or with dogma.
(Likewise, you can use all of this to moderate your own criticism of other people’s CSS: Is it really “wrong”—as in, it doesn’t work, and they wouldn’t even bear the consequences?)
_ In the end, CSS allows to solve a myriad of design and interaction problems in a myriad of different ways. The platform controls how these ways are applied, exposed, and managed. Because of both, there isn’t really “wrong” in CSS.
Many thanks to Ahmad Shadeed for reviewing this post.
About Me
I’m Jens (long: Jens Oliver Meiert), and I’m an engineering lead, guerrilla philosopher, and indie publisher. I’ve worked as a technical lead and engineering manager at various companies, including Google; I’m an open-source developer and a 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 with respect to politics and philosophy. Here on meiert.com I talk about some of my experiences and perspectives. (Please share feedback—interpret charitably, keep it friendly, but do be critical.)