On Declaration Sorting in CSS

Post from September 24, 2014 (↻ October 19, 2022), filed under Web Development (feed).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development. If the optimization of CSS is of particular import to you, I’ve collected several concepts in a brief book: CSS Optimization Basics.

I keep on seeing people advocate to sort declarations “by type.” And every time I wonder, why is this idea still going around?

Type sorting is extraordinarily ineffective, for it’s extremely slow and consistently unreliable (or reliably inconsistent). Even lead developers are witnessed to forget and break the type sorting rules they put in place. On top come type sorting’s problems dealing with the constant influx of new properties that regularly threatens re-categorization. Accordingly, we observe CSS sorting scripts to require to maintain property tables and such. Type sorting is just not an efficient, nor a practical way of sorting declarations.

/* Type Sorting */
foo {
  position: absolute;
  top: 0;
  right: 0;
  width: 100px;
  height: 100px;
  background: #000;
  color: #fff;
  font-family: fantasy;
  font-size: 1.5em;
}

In comparison, declarations are easily sorted alphabetically. Alphabetical sorting is so easy that it has over the years (and I’m sure someone had standardized it before 2008) turned out to be the fastest and most reliable way of sorting declarations. It’s simple to automate (tools like Clean CSS offer it for a while), but works reliable when done manually, too.

/* Alphabetical Sorting */
bar {
  background: #000;
  color: #fff;
  font-family: fantasy;
  font-size: 1.5em;
  height: 100px;
  position: absolute;
  right: 0;
  top: 0;
  width: 100px;
}

Based on many years of experience in many different environments I can only, and that strongly, recommend to sort declarations alphabetically. We can just keep things simple. The only other alternative that means little work for us is not sorting. And not sorting is not useful, for structured code is more manageable and more maintainable code.

With that said, where it gets dicey and where we’re falling short instead is sorting of selectors and rules. I believe a few of us have tried to come up with an organized attempt at selector and rule sorting, too, but what we have—and I would like to chip in last year’s comprehensive selector order draft—can probably be improved. An additional challenge, due to the cascade we don’t have a good lever to crack this with tools. I think selector and rule sorting would be a more interesting topic for us to tackle than making our lives unnecessarily complicated by sorting declarations “by type.”

About Me

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!

Comments (Closed)

1. On September 24, 2014, 17:57 CEST, Brad Czerniak said:

   How do you deal with prefixed properties?

2. On September 24, 2014, 18:03 CEST, Jens Oliver Meiert said:

   The same way, though I think what we’ve standardized at Google works, too.

3. On September 24, 2014, 18:12 CEST, David said:

   I too never understood why ‘by type’ was more efficient or preferable. I’ve always sorted alphabetically. I manually write in a compressed format and find it to be wonderful to scan large CSS files quickly when alphabetized.

   Brad - If you’re using Less, Sass, etc., most pre-processing scripts/applications use auto-prefixing scripts in their build process. This eliminates the need to worry about prefixing.

4. On September 24, 2014, 18:25 CEST, Rupert Breheny said:

   Nice post Jens, and I have you to thank for my alphabetic approach now. There are a couple of caveats: specifically vendor prefixes being shuffled to the top of a style block.

   SORTED
     -webkit-transform: rotate(45deg);
     position: absolute;
   transform: rotate(45deg);
   

   There can also be issues of course with overrides to shorthand:

   NOT SORTED
     border: 1px solid red;
     border-width: 10px 1px;
   

   Sorting that would break the intended behaviour. Otherwise the exceptions that prove the rule?

5. On September 24, 2014, 19:04 CEST, Vadim Makeev said:

   Since you can use CSScomb plugin for your code editor (or grunt plugin for post-processing) sorting by type is useful again. CSScomb is not just a tool for sorting, it’s also formatter.

   Personally I can’t live without sorting because when I work with width I need height as close as possible, not white-space; I need bottom right after position not after border; font is pretty useless close to float, etc.

   There’s also easy sorting way, to have groups:

   1. Positioning and block properties (float, dimensions)
   2. All sorts of colour decoration (border, background, box-shadow)
   3. Text (obvious)
   4. Special effects (opacity, transitions, etc.).

   Have you actually tried it?

6. On September 25, 2014, 13:33 CEST, Jens Oliver Meiert said:

   I had checked out CSScomb, Vadim, and it looks great 😊

   Alas (when it comes to sorting), as great as it is for automation, it doesn’t solve the issue that type sorting is too cumbersome to be a manual option (I do believe we need something that works for manual sorting, too). And I think CSScomb also struggles dealing with new properties and re-categorization, but maybe you can share more? (I just checked out the docs again but can’t find how it handles type sorting exactly.)