Sunil Chaudhary

Posted on Oct 6

The CSS Casing Wars: A Survivor's Tale.

#webdev #namingconvention #css #sass

The CSS Casing Chaos: My Beef with CSS Casing

Confession time: I'm a developer with a bad case of Code-OCD. For the past decade, I've found a strange sort of peace in the predictable, orderly worlds of different programming languages. I love that Python developers collectively decided snake_case_is_the_way, and the JavaScript community embraced camelCaseLikeThis. It’s clean. It’s uniform. It’s consistent.

And then there's CSS.

Oh, CSS. The Wild West of the web. It's the one place where every project feels like a new frontier, and the local naming convention is "anything goes." In my travels, I’ve seen them all:

kebab-case: the-good-stuff
camelCase: theWeirdStuff
PascalCase: TheTitleStuff
snake_case: the_confusing_stuff
And my personal nightmare: an unholy mix of all four in the same file.

😱

Just peek into the developer tools of a few major websites. It’s often a tangled mess that makes my eye twitch.

Examples

Below are statistics from various sites on different percentages of css being used by them in their homepage. Key observations:

Facebook and Instagram seem to be most consistent in classname naming convention.
Amazon seems to be following good old kebab-case.
LinkedIn seems to be using mix-up of classes.

snippet used to gather this data

Gmail

Facebook

Instagram

Amazon

Flipkart

How did we, an industry obsessed with standards, let this happen?

The short answer is that CSS wasn't designed for the complex world it now lives in, and the community built solutions in fragmented ways before any single standard could emerge.

Here are the key reasons why we, an industry obsessed with standards, ended up in this naming mess:

1. Humble Beginnings: It Was for Documents, Not Apps 🌱

When CSS was created in the mid-90s, the web was a collection of static documents. Its primary job was simple: separate content (HTML) from presentation (CSS). No one imagined we'd be building massive, interactive applications with it. The problem of large-scale, maintainable CSS with dozens of developers simply wasn't on the radar. We started with a garden shovel and are now trying to build a skyscraper with it.

2. The Browser's Forgiving Nature 🧐

Programming languages like JavaScript or Python have strict rules and linters (like ESLint or PEP 8) that yell at you for inconsistent syntax. Browsers, on the other hand, are incredibly lenient with CSS. A browser’s main goal is to render a webpage, not to enforce stylistic purity. As long as a class name doesn't break basic syntax rules, the browser will accept my-class, MyClass, or my_ClAsS without complaint. There's no built-in "gatekeeper" to enforce a single convention.

3. Community Solutions Created Competing Standards

As web applications grew more complex, developers felt the pain of messy CSS. Instead of a single, top-down standard being created, brilliant developers from the community came up with their own solutions to manage the chaos. This gave us:

BEM (Block, Element, Modifier): nav__item--active
SMACSS (Scalable and Modular Architecture for CSS)
OOCSS (Object-Oriented CSS)

These are fantastic methodologies, but they are competing philosophies, not a universal standard. It's like if different groups invented their own traffic rules for the same city—all are trying to solve the problem, but the result is still fragmentation.

4. The Tooling Revolution Added Another Layer 🤖

Then came the modern tooling era with SASS, LESS, CSS Modules, and CSS-in-JS. These tools were game-changers, solving major problems like variable management and scope leakage. However, they also introduced their own unique ways of working:

SASS/LESS allowed nesting, which created its own naming patterns.
CSS Modules and CSS-in-JS often generate unique, hashed class names (.header_title__a34Bf) to guarantee styles are scoped. This makes the human-written naming convention less critical for preventing conflicts, so the focus shifted away from standardizing it.

In summary, it wasn't a single decision that led us here. It was a slow, organic evolution where the problem grew faster than the language's core ability to manage it, and the community patched the gaps with a diverse and brilliant—but ultimately fragmented—set of tools and ideas.

So, that explains the chaos, but it doesn't excuse it. We're standing in a mess created by historical accidents and competing ideas. While we can't rewrite the past, we can choose a clearer path forward. For me, that path starts with a simple, foundational choice

Given this complex history of competing methodologies and powerful tools, it’s easy to feel like the problem is too big to solve. But what if the first step toward sanity is much simpler than adopting another framework? What if it begins with looking at the native language itself for guidance?

My Hero: The Humble Kebab

If I had to plant my flag on one hill, it would be for kebab-case (main-navigation-link). It just feels native. CSS properties themselves are written in kebab-case (font-size, background-color, align-items), and so are HTML attributes (data-user-id, aria-label). Using kebab-case for class names creates a beautiful, harmonious flow between your HTML structure and your CSS rules. Everything looks like it belongs together.

Now, I know what you’re thinking. "But what about BEM!?"

Sure, methodologies like BEM (block__element--modifier) are a fantastic effort to bring structure to our stylesheets. They are a godsend for organizing complex components. But here's the catch: BEM tells you how to structure the relationship between classes, not the fundamental way to write the words themselves. You can still end up with MainMenu__Nav-Item--isActive, which is a stylistic Frankenstein.

Two Pleas for a Tidier Future

So, where does that leave us in this beautiful, chaotic mess? I believe the path to CSS sanity lies in maybe a two-pronged approach.

1. The Grassroots Pact: What We Can Do Today

My first plea is to you, my fellow developers, fighting in the trenches of daily code. Let's make a pact. Pick a convention and stick to it with fierce loyalty. My vote is for the humble kebab-case, as it aligns perfectly with CSS's native syntax. But honestly, even if your team chooses camelCase or snake_case, the win is in the consistency. Agree on a style, document it, and enforce it. Future you will be grateful.

2. The Big Picture Plea: A Call to Framework Architects

My second plea goes out to the brilliant minds building the frameworks and tools we love. In the JavaScript world, frameworks like React, Vue, and Svelte don't reinvent the language's syntax; they embrace its standards (camelCase variables, PascalCase components).

Why can't we have that for CSS?

I understand that many modern tools auto-generate hashed class names (.cz13b8) to prevent conflicts, making human-readable names less critical in production. However, the source code—the component files and style sheets we actually write—is where the chaos lives. A plea to the framework architects: Promote and adopt a single, consistent naming style for the code we write. Let's build that consistency right into the tools we use every day.

Until that glorious day arrives, you’ll find me in my projects, acting as the lone sheriff wrangling every stray camelCase and outlaw snake_case I can find. A little consistency, after all, is all a developer with a twitchy eye for clean code can ask for.

Is that really too much to ask?

(co-author: Google Gemini Pro)

DEV Community