Wrong CSS doesn't exist — here's why. From backwards-compatibility to platform responsibility, find out why CSS advice is context, not law.

SitePoint is a  web development resource that offers tutorials, articles, and courses covering a wide range of topics, from frontend technologies like HTML, CSS, and JavaScript to backend frameworks and tools like Node.js, PHP, and Ruby on Rails. With a focus on practical, hands-on learning, SitePoint provides step-by-step guides, code samples, and real-world examples to help developers master essential skills and techniques. Whether you're a beginner looking to learn the basics of web development or an experienced developer seeking to expand your knowledge, SitePoint offers resources to support your learning journey.

SitePoint

There is no objectively "wrong" CSS, and four reasons support this claim. First, if CSS works without practical disadvantages, there's no reason to change it, especially given the web platform's strong backwards-compatibility guarantees. Second, any consequences of suboptimal CSS fall on the developer or organization, making it their call to address. Third, CSS is easy to refactor when a better approach is needed, so no mistake is truly grave. Fourth, when CSS creates real barriers for users, that's arguably a platform-level responsibility rather than a developer failure. CSS advice should always be understood as context-dependent guidance, not universal law — and distinguishing advice from dogma is key to evaluating criticism of your code.

There Is No “Wrong” in CSS

4. Barriers for Users Are a Web Platform Responsibility

But What if Someone Still Says Your CSS Is Wrong?

Oh, there can be a lot wrong with css

Clearly, this author has never looked at the CSS that comes with WordPress plugins. 😂

The author’s mistakes are most prominent in 1, 3, and 4.
1: Oftentimes, it’s challenging to evaluate if “it works”. Issues w.r.t. accessibility, responsiveness, and platform independence (e.g., font-related) are difficult to notice. Staying with best practices mitigates much of the effort to evaluate if “it works”. For heaven’s sake, we don’t even have a standard screen reader to test against; it’s all a “design for the popular choice” mess.
3: It’s not easy to change if it’s central to your page. Changing <code>display:block</code> to <code>display:flex</code> for wrappers, for example, if some components also use <code>@media</code> breakpoints to change how they wrap… That’s a hell of a refactoring and will only grow if you postpone. So, yes, there is a “right” solution. Another example: hard-coded color values everywhere… A mess that grows beyond fixability.
4: Web Platform Responsibility and Backwards Compatibility don’t work well together. If you used table layout in the past, you don’t have proper semantic indicators for the Web Platform to have the possibility to fix this. This is why modern HTML + CSS focus on semantics instead of just “it works”. That’s why the “old way” is wrong.

Definitely wrong way of thinking, sooner or later you will get some cases when that “is okay” will cause some visibility trouble on a device/browser, and then you will have to deal with a much bigger picture at that point, instead of writing it properly now and using properties properly with some ground rules placed.
Even if CSS doesn’t work directly with business logic, it presents a part that works with that logic, and it has to look and work well