On Declaration Sorting in CSS

Published on September 24, 2014 (ā†» February 5, 2024), filed under (RSSĀ 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.ā€

Toot about this?

About Me

Jens Oliver Meiert, on September 30, 2021.

Iā€™m Jens, and Iā€™m an engineering lead and author. Iā€™ve worked as a technical lead for companies like Google, Iā€™m close to W3C and WHATWG, and I write and review books for Oā€™Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. 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 (where applicable) or aĀ message.

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.)