There are a few schools of thought when it comes to organizing your CSS declarations. Each approach uses an underlying concept to impose a specific declaration order.

When I say organizing declarations, I’m talking about the CSS code placed inside selectors, not an approach to organizing Sass partials.

Two examples of CSS declaration ordering that come to mind are:

  1. Jonathan Snook’s SMACSS.
  2. Anton Korzunov’s stylelint-semantic-groups.

There are other examples out there, equally as thoughtful and purposeful. As someone who is really, really into CSS, I wish I could enthusiastically recommend an approach other than alphabetical. However, I’m unfortunately here to tell you not to.

The most common CSS declaration organization technique I come across is none whatsoever. I say this with the authority of a seasoned consultant who has worked on multiple project codebases spanning multiple organizations and departments.

Where we’re going we won’t need eyes to see

I’ve seen CSS ordered by adding to the bottom of the selector. I’ve seen CSS ordered by arbitrarily adding properties everywhere until it looks right in the browser. I’ve seen CSS ordered by a teetering pile of irrelevant and non-functioning copy/paste code from StackOverflow. I’ve seen CSS ordering by way of generations of vestigial framework overrides. I’ve even seen multiple approaches smashing into each other by way of generations of employee work, revealed only after spending time teasing the story out of commit messages.

The problem is that CSS is still misunderstood, undervalued, and dismissed as a trivial concern. The reality is that it is the programming language used to give ideas shape.

We live in a highly visual culture. Your product won’t earn a single penny if it doesn’t have a polished, visible form to communicate value.

Until there is movement on developers taking CSS more seriously and understanding its full capabilities, we are caught in an awkward loop where introducing too much complexity in your project’s CSS will do more harm than good.

Other programming languages share this meta issue. Too much abstraction or clever code means it becomes exponentially more difficult to understand, maintain, debug, or expand on existing work. It also means more ramp-up time for getting someone up to speed on a project (not that we’re doing much of that these days).

If you can’t be correct, at least be consistent

I recommend alphabetical order because it imposes a baseline sense of structure across a team. This ask is usually enough, especially if it means cleaning up what’s come before.

Alphabetical is easy enough to pick up and have an organization repeat as a convention without having to invest too much time on upskilling an entire team on CSS theory.

This is a bummer because investing in CSS theory makes for better overall results—declaration organization approaches other than alphabetical do communicate, and therefore teach more advanced CSS concepts.

Directed effort

The last thing I want to do is set my client up to fail. It’s difficult to recommend any approach that I don’t think the organization has the ability to maintain after the engagement ends, even if I personally think the approach is better.

I think this is an important thing a lot of people get wrong. You want to set up something sustainable, but also not pour your own energy into making the right thing in the wrong way just to satisfy your own personal desires.

Why teach anyone anything?

You want to create understandable solutions, but also repeatable practices. The shape of that varies across individuals and organizations.

A big part of doing this well is having conversations about is known measured against what can be internalized and sustained. If you’re lucky, that’s enough to foster a sense of exploration that will open doors to more advanced concepts.

The great divide

Unfortunately, I don’t see the needle moving on CSS being taken more seriously any time soon. This means I’m stuck in this loop with everyone else, even though CSS keeps getting better and better.

To the earlier point of code being too clever, this is not that. This is a scenario where platform features are going unused due to bulwarks we’ve constructed around learning.

These concerns aren’t abstract, academic quibbling. They have a direct impact on things like performance and accessibility, concerns that map directly back to a person’s experience (or lack thereof) in using a website or web app.

Don’t punch down

I’m reluctant to blame developers for this lack of knowledge, especially new ones. As an industry we do a terrible job at teaching anything other than JavaScript. I’m also hesitant to blame the schools. They teach what the market demands, which is another loop we need to break.

We can do so much better than hope a handful of people break through an echo chamber of misogynistic rise-and-grind javagrifters preying on the ignorant.

We need better educational infrastructure for learning design and development. I think a large part of that are formalized trade apprenticeships, but that’s a different post for a different day.

Similar Posts