I really do appreciate the nesting they've added but looking at it as a whole, CSS is a really strange and in my humble opinion, a terrible language. Perhaps I'm just holding it wrong, but it's just so complicated and messy, it sometimes feels like you're just arranging arcane runes in different ways until you make it sort of work for you. It's both a system for styling text based on inheritance, and a layout system for block and inline elements, nested recursively but without inheritance, only containment. I think it was a mistake to combine styling and layout, and I don't feel like adding more and more capabilities to something fundamentally broken can fix it.
CSSdev has been the bread and butter of my last 10 years of work, and I still have the feeling that CSS as a language is never designed, just expanded.
A series of modules that are bolted on top of existing properties without actually improving on them, simply "well, here's another way of doing the same thing" often in ways contradicting each other (see the way the box model works in "display" vs "flex" layout) or just slightly diverging in ways that make extremely hard to debug them (e.g. how gap works in "flex" vs "grid" layouts[1]).
The awkward point-based cascading system means that once a layout is written it's basically frozen, unless you use some convoluted native or js-based encapsulation systems which once in a while gets leaky and, who knows, your component topbar font-weight mysteriously goes from "thin" to "extrabold" or your mobile menu appears even on your desktop breakpoints.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/gap
I disagree, I think most of these opinions I see about CSS are from people that haven't taken the time to learn it and particularly to understand the cascade.
Many years ago I did a very deep dive into the CSS specs as I was researching for a new implementation and it struck me as well designed for its purpose of separating style from the semantics of markup.
IMO the cascade is the exact problem with CSS. It worked fine when all it was dealing with was super simple documents with a few rules here and there, as soon as we started making applications the cascade causes endless headaches, and most modern methods of handling CSS like modules or libraries like Tailwind are made specifically to avoid cascade/specificity issues. Conceptually CSS is not really all that complicated, but in practice when you have dozens or even hundreds of CSS files for an entire app, it simply becomes a herculean nightmare to deal with and to wrap your head around.
As someone who works with many dozens of CSS files each day, I can say the problem isn't CSS. It's devs who are too lazy to document their work.
If everyone is working from the same spec/reference, it's fine, and you get consistent, reliable results.
When devs have to stumble around in the dark and end up reinventing the wheel every few months, that's when things go badly.
> devs who are too lazy to document their work
That's as bad a complaint as the one about cascading.
Your rules should be close to the object that uses them. It's really bad that CSS only supports global rules, and that is not a fault of the developers writing those rules.
When the !important comes out it's all over
It has been my experience that those that complained the loudest about CSS, expected to know it without actually studying or learning it. They already know a "real" language, so why should they have to study a "toy" styling language.
When it comes down to it, making a great looking and maintainable page is just as much work and planning as building a good backend codebase. Neither one just happens.
This problem is compounded by CSS kind of overlaying HTML in a way.
Lots of "real" devs treat HTML with similar "I don't need to really learn this toy markup" kind of attitude. The worst CSS issues I've ever had to deal with were often caused by horrible markup that was impossible to consistently style.
Basic stuff like how to make a good `<form>`. Putting `<label>` elements next to your `<input>` elements, or making sure the `for` and `ID` attributes are set. Hell, even using `<label>` instead of some `<span>` they threw a bunch of random framework classes on.
I think developers nowadays being coerced into being a jack of all trades, master of none contributes to CSS being the least studied and practiced by full stack devs. Such devs would also be much more inclined to put their time into, for example, learning and practicing databases rather than improving their skills regarding UIs, and for webdev that means skimping on CSS while just doing the bare minimum, mediocre thing to get it working.
I is certainly true for me that I didn't take the time to learn the intricacies of CSS behavior and I still think the cascading properties are the worst feature, namely concepts like specificity. It is hard to keep a mental model of styling rules and at some point it is just degrades to trial and error.
Nobody came up with a better alternative though (apart from the many dialects that transpile to CSS again).
In 2025 when starting from scratch all you really need is flexbox, css grid, and the box model and that will get you like 99% of the way on most layouts.
Specificity is really just
* ids take priority * the highest number of specified classes, and if there’s a tie it’s the first one specified * the highest number of types
The only problem is that most paths in frontend development say “slap a class on an element” and call it a day but you do need to be intentional about it and only specify what you need
What about CSS layers[0] doesn't solve your specificity issues?
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/@layer
Video games became a lot better when developers stopped saying, "You just haven't taken the time to learn it and don't understand it", and started saying, "That's my fault for designing it that way. Let me redesign it so that it's accessible to everyone in my target audience". I wish programming languages would be humble enough to do the same (although many are!).
The problem here is that it wouldn't matter if you made a better language for styling web pages, because you have no vector to get that language included in browsers; and even if you did it would take years for it to get enough market penetration for you to rely on it as something you can deliver an app in. So, you'd end up with some horrendous compatibility layer that compiles everything down to nasty CSS anyway.
Same problem with Javascript. Here we are compiling Typescript down into it... and running JS on the server with Node in order to avoid the classic impedance mismatch we all had back in the day writing backends in PHP etc.
Feels like the real solution would be to allow browsers to become more flexible with language implementations instead so we can make more progress. WASM might be the ticket there?
All that complexity is a trap. It creates a need for people that have spent the unreasonable time to grasp a poor design, and then they have the secrets that others simply do not have the time to waste learning yet another poorly designed reindeer game. That complexity eats time, energy and is pointless. CSS is a shit show of poor design, poor documentation, and secrets.
What secrets are you talking about?
All the edge cases.
Do you have any concrete examples?
How's about the very existence of different layout engines, which can all be in-use at once on the same page?
So, what is your proposal?
Throw away the front-end of the Web and start over with a system actually designed to facilitate graphical applications instead of delivering styled documents.
HTTP can stay, and HTML/CSS can stay just like PDFs for delivering a document, but when it comes to UI components, we should be able to have things as fast and performant as e.g. RedLang / Processing / Enlightenment DR17 / etc without every developer having to shovel megabytes of shim-ware down to the client.
That's a good solution in a perfect world. But that's magical thinking. What's a real solution?
We have a plethora of native frameworks for building UI-s. Some of them are quite well designed. And yet the Web front-end has won against all the UI frameworks designed specifically to build UI-s.
That’s partly due to reach, though. The combination of the browser coupled with Electron eating away at those native UI layers means it unfortunately makes little sense to bother with alternatives, even if the alternatives are better.
I.e, the GP is trying to argue one thing and you’re kind of going down a different tangent.
The problem with CSS is the C: Cascading. Which is what you are calling "inheritance"
Cascading is a nice feature for documents, that present data in the same way over and over. It not good for anything interactive. A lot of modern styling techniques are all about making CSS _not_ cascade. UI components (which is the majority of modern frontend dev) is basically a pre-requisite to achieve that.
The layout system is a bit of a separate discussion, and it is a mess yes, but mostly for backwards compatibility. If we could live in a world where all layout is default flexbox or grid and never mix inline with non-inline in the same container it would work out just fine. In fact that is _exactly_ how it works in React Native and it doesn't cause problems there. Styling in React Native also doesn't cascade which also makes it a lot easier to manage.
> I think it was a mistake to combine styling and layout (...)
Anyone who ever did any work on UI development knows very well that styling and layout are coupled and interdependent. I mean, think about it. Text string length, text size, text overflowing/breaking/clipping, margins, etc. You change border sizes/padding/spacing and the space left for child content changes as well. How exactly do you uncouple something that's fundamentally coupled?
I think that's true, but I think there's a more fundamental mistake in thinking that you can uncouple the HTML structure from layout, particularly when the layout rules make explicit reference to "parents" and "siblings".
The dream of CSS was that you could decouple styling from semantics. Your HTML would tell you what the page meant, and then your CSS would let you present it in whatever format was prettiest, and you could swap out CSS to let different users view it differently. But in practice, what happened was that the page ended up meaning nothing - it was just an app, a way for the user to accomplish a task, so instead of <h1> through <h6> and <p> and <em> and <cite>, everything is a <div>. The very concept of CSS was flawed, because we still thought of websites as documents at the time it was invented, rather than as an app platform.
That's perhaps why newer reactive frameworks like React or Jetpack Compose ditch this separation. The style in React is to just include CSS inline on the components. In Compose, you have Modifiers that let you specify the styling as explicit attributes on the component. They admit that they're building a UI framework, not a document overlay, and get rid of the content/presentation separation as a result. It's all presentation.
Who misses csszengarden
It still exists!
https://csszengarden.com/
What doesn't really exist is the excitement about the web as a publishing platform. Those of us who still write CSS for a living probably do so in the context of a webapp, a product that's trying to help a user accomplish a task. We usually work with other developers, and writing CSS like you do on CSS Zen Garden would probably get you fired. If you are an indie publisher maintaining your own website where you can actually control the CSS - get ready for spam, and hackers, and bitcoin miners, and people using your server as a launchpad to do illegal things and get you blamed for it!
Social media won, and it's social media like Facebook or TikTok or Reddit where you have zero control over presentation, not even social media like MySpace or LiveJournal where you could do cool things with CSS.
BTW I remember not being excited by csszengarden and I knew one guy being excited about it. I'm still not excited tbh, I miss flash and photoshop heavy websites.
This is all true. But it is what we have. I’ve found myself wondering if a model with stronger conceptual integrity could be designed and use CSS as a compilation target. For example, with container queries and calcs you could probably implement a more coherent layout system with just math.
Unfortunately the preprocessor languages we have just add even more half-baked ideas on top of the half-baked ideas already in CSS, according to the principle that syntax sugar = good.
Tailwind is the closest popular thing to that and it's no wonder it's become so liked. Not so much in terms of providing a better layout system, but it just removes so much of what's wrong with CSS, at least for those who don't like it.
I haven't seen anything out there that provides an alternative but it does seem like CSS has almost added enough features you could actually build something that works. Alternatively it could be done through higher level abstractions built on something like React: <Flex>, <Grid> etc.
that's a great observation. previously to (finally) trying Tailwind for the first time, I would write utility CSS classes to handle those cases like a stack or grid and it worked great building alone. Unfortunately, CSS is really hard to do with others, especially in a big team. Classes always added instead of using the existing one, nothing ever cleaned up. Tailwind is nice in that you get all the power of CSS, just a bit more ergonomic of an API. Plus using it really is just using CSS, just with all the possible utility classes already made for you!
that said i do like to still use classes like "btn" to consolidate a bunch of styles. I think it was a mistake for TW devs to discourage that pattern for so long.
> "I think it was a mistake to combine styling and layout"
Perhaps because we can have different styles of layout, it fits with CSS better than you say. Carefully designed padding, margins and negative space is both a style and layout consideration.
Containers contain styles, but the container's relationship with other containers may tie with presentation such as border thickness, colour, shadows, and let's not forget animation and interaction effects on containers. Maintaining control of these aspects in one place makes good sense to me.
CSS1 circa 1996 was (practically) styling only. It's main purpose was decluttering HTML of all the font tags etc.
CSS2 included limited layout, but support in popular broswers lagged for so long that practically nobody learned the standard, just the vibe styling voodoo to get certain browsers to kinda partially work.
I read up until the css color picker (which doesn’t work in Safari), clicked view source, and then scrolled… and scrolled… and scrolled… until my eyes glazed over and I tapped the back button to get here. It just looks so messy and hacky, but might just be me.
i think css is one of the most brilliant languages
but you have to separate the specific properties (float) and the semantics of the language
the selector system is incredible, in a way i can’t quite describe why but it feels similar to programming in prolog
inheritance is kind of stupid for most things yes, but `all: initial` is a easy fix / debug
to me the part i love is the debugger (dev tools) and the ability to plop down code where ever and it just works, code organization is just writing good selectors
unfortunately i don’t get to do this professionally so the largest css files i work with are 1000 lines, and usually no shared libs, but i find it extremely fun to work with
Nothing's perfect, Javascript has evolved too as a core language the more it's used.
“I believe a lot of the negativity towards CSS stems from not really knowing how to use it. Many developers kind of just skip learning the CSS fundamentals in favor of the more interesting Java- and TypeScript, and then go on to complain about a styling language they don’t understand.”
from the article is talking about people like you, who refuse to learn something properly but have the arrogance to think they know better.
I don't have the time to spend weeks for every little tool to study its details and edge cases, I simply want to use them and get stuff done. If a tool is actively counterintuitive and hostile to its user, then it is flawed and it is no wonder users will seek out alternatives.
>I refuse to learn the tool properly and blame the tool instead of my laziness
Ok
Yeah, of course I'm lazy, why would I want to do unnecessary extra work? If a tool has bad UX that demands more effort than it should, I will find a different one. I have a limited amount of time to spare. If there is no other tool, I'll do a "good-enough" job and move on to more important tasks. Luckily, alternatives usually exist. Krita instead of Gimp, Cuda&OpenGL instead of Vulkan, C++ instead of Rust, etc.
there's two types of workmanship, where one camp focuses on becoming more and more proficient with progressively more advanced tools and the other focuses on blasting through the piecework as quickly as possible. obviously the latter is much more common, but on a site such as this there still exist faint traces of the former.
That's incredibly arrogant phrasing by both you and the author.
Here's a better explanation of the hostility towards CSS.
Nested flexbox had bugs in IE11, which wasn't end of lifed until 2022. The nested CSS in the article came out in December 2023.
CSS first came out in 1996.
The current state is much improved, but don't pretend there wasn't a solid 20+ years of sucking before that.
I’ve always found CSS trivial to use and I’ve done some complex styles. I really wonder what people who complain about CSS are doing.
>Nested flexbox had bugs in IE11, which wasn't end of lifed until 2022.
how is I hate CSS because IE was poorly maintained a serious argument?
For a long time, from the late 90's until roughly 2012, IE was the most popular browser. You had no choice but to work with it. If it didn't "work on IE", it didn't work.
I don't think flexbox really started being used until 2013 at the earliest, the comment I replied to was complaining about 2022 and a flexbox bug in IE. This 2012 thing doesn't seem to relate at all to the subject.
on edit: I know it was in WD in 2009 but I'm pretty sure it was around 2013 that people started playing with it. I think it started being popular in 2014-2015.
My comment was more about the prevalence of IE in general, not flexbox specific. There were tons of IE quirks that had to be dealt with.
Yea and people over exaggerated about it just like people over exaggerate things today like how hard CSS. The technology progress but people’s refusal to learn and desire to whine on the internet has stayed the same.
This is true, but the dominance of IE and its quirks, especially during the early 2000's, should not be underestimated. The browser situation, especially on Linux, was absolutely abysmal then.
They will cling to any cope they can because it’s easier than learning the tool properly.
“It’s not MY fault, it’s a browser no has used in 10 years fault! I can do no wrong!”
You can apply that line of argument towards anything though, it's not particularly insightful.
Yes refusing to learn to program, draw, drive or whatever properly and then complaining about it is stupid and provides more insight on the person than the activity.
There’s nothing more arrogant than doing something wrong/badly and then blaming the tool for the outcome and not yourself.
Perhaps the only thing more arrogant is to assume someone who criticizes something simply doesn't understand it.