A DevOps engineer popped into our office with a question: “Does anyone know CSS?” In a room full of frontend developers, everyone remained silent. You might think, “Okay, are they juniors?” Well, not really. They ranged from 3 to 8 years of experience. The truth is, no one really knows CSS, and I’ll explain why.

Languages in software development, even CSS (which is sort of a language, although that’s a different debate), should follow similar “design” patterns as natural languages. They are the way for a software engineer to communicate with a machine in a way that’s easy to understand for humans. So, languages in software development should be made by humans for humans. CSS is (probably) made by humans, but certainly not for humans.

Now, let’s start from the beginning. When HTML was invented, it was designed to share simple text over the internet. Like in any textbook, you would have pictures here and there. So, there was a need for a way to insert images seamlessly into the text. That’s why float exists. Also, text needed to be presented in tabular data, which is why “Table” exists in HTML with its properties.

As the World Wide Web grew, designers started getting more creative with layouts and website presentations. People began creating layouts similar to grid design. In what is now ancient history by internet standards, people used tables and floats to structure their grids. The problem with floats and tables is that they weren’t designed for layouts. This led to “div and CSS soup”—really hard-to-read and understand code. To mitigate that problem, the first frameworks began to emerge. We had the first version of Bootstrap from Twitter almost 15 years ago. Around the same time, flexbox was proposed, and teams behind CSS began working on it.

The main goal was to eliminate the need for float/table hacks for layouts. In 2013, flexbox was introduced. Did it solve the problem of float/table hacks? No, not really. It created a 2-dimensional “Flex” ribbon of sorts. It’s not really intuitive, at least not to me. I understand it now, but I had my share of struggles trying to figure out how it works.

So, now we have three ways to create layouts:

Floating elements Tables Flexbox Okay, one would assume that flexbox is the final model, right? No more hacky ways or smelly code to create layouts. Well, not really. Let me remind you of something: a language should be “for humans.” I’ll start with my own experience—flexbox isn’t really designed for humans. You might say, “That’s just your opinion,” but I believe the truth lies in tradition. What’s the goal of CSS? To code DESIGN into a rendering engine and produce the same layout. And what have designers used since the industrial revolution? The GRID design system. So, Microsoft, despite its flaws, gave us some great things (like TypeScript, ahem). But in addition to that, the grid system came from Microsoft. And voilà, we now have four ways of implementing CSS layouts. How many frontend developers know all of them really well? Almost none. Pick a random frontend engineer and ask them to create simple layouts using each one. Most probably couldn’t do it. I’d bet on it.

And that’s just layouts, one small part of what CSS is used for, but something every frontend developer deals with daily on both legacy and new projects.

Now comes the fun part. There are around 500 CSS properties and about 1,920 CSS references on MDN (I counted). How many frontend engineers know them all? How many know at least half of them? I could cherry-pick a segment of those properties and write an article about them—their history, usage, intended, and unintended applications today. It would probably take a book.

The point is, no one really knows CSS—not even frontend veterans. If they say they do, they’re lying. They know just enough to be good at their job, but not much more. It’s a poorly designed language with a lot of confusing behaviors and implementations, many of which rely on hacky solutions that frontend developers have figured out over time.