Let me take you on a journey. In the beginning, I was using Sublime Text 2 (ST2) as my primary code editor. Then, Sublime Text 3 (ST3) came out and people at my company began to switch. They were raving about how much faster it was, the native image preview support, etc. So I decided to switch.
Most of the packages that I used in ST2 were also supported in ST3, so I didn’t see much of an issue switching. The most major change was the Sublime Linter plugin that was I using for JSHint. In ST3, the linter package was turned into a package/subpackage module where you would install Sublime Linter, then install other linters as subpackages to Sublime linter. This included new linter support like HAML and SCSS which I was interested in trying out… Thus began a several month journey battling with bundler, the scss-lint gem, node, the npm JSHint package, $PATH variables, .bash_profile files, etc, etc. It was a mess. Then another coworker turned me onto Atom… and all my problems went away. JSHint and SCSS Lint worked out of the box and I haven’t run into much trouble since…
So now that you have that truly informational back story…
SCSS Lint Sorting and CSS File Size
So since having SCSS Lint setup, I’ve added a .scss-lint.yml file to all the projects I work on in order to enforce SCSS code consistency between all the people that work on the project. I decided to limit the modifications to the “default” rules of the SCSS Lint in order to reduce the learning curve when bringing on new people to the project. It seems more likely that others might be using the defaults, rather than some custom rules I deem valid for my own personal taste. That being said, the one thing I did decide to change was the default sorting order. I chose the “concentric” sorting order because it grouped similar properties. In the past I liked to keep the “box model” styles together, font and text styles last, etc. Concentric offered this same philosophy, but enforced it in rules for the SCSS Lint.
Things were going great, then one day Dave Barnow, a team member, saw an article that mentioned alphabetically sorting of CSS reduces the file size of the CSS because GZIP will find similar strings and be able to compress them more easily. This got me thinking, that if GZIP works better with alphabetic sorting than no sorting, surely Concentric would be even better… When setting a “position” on an element you typically also have a top, right, bottom or left rule as well. It seems likely that these would often be grouped and their give GZIP greater power when compressing.
So I decided to test my theory. Along the way I ran into CSS Comb. CSS Comb can be installed into your code editor and will sort your CSS for you with a keystroke. I’ve known about CSS Comb for a while now, but have never really utilized it too much, because the automation of it all felt too unwieldy. That being said, CSS Comb offers 3 more variations of sorting that I added to my list as well, CSS Comb Sorting, Zen Sort, and Yandex Sort.
I decided to use a WordPress Admin CSS file for the sorting experiment. I’ve worked in the WordPress Admin CSS before, and I knew that, with so many people contributing to it, that it probably was sorted in any particular way. So I duplicated the file a bunch of times, and sorted each of them with the following:
- No Sorting (control) – wordpress-themes-org
- Zen Sorting – wordpress-themes-zen
- CSS Comb Sorting – wordpress-themes-csscomb
- Yandex Sorting – wordpress-themes-yandex
- Alphabetic Sorting – wordpress-themes-alpha
- Concentric Sorting – wordpress-themes-concentric
After sorting I ran each file through an online YUI compressor and output the result as gzipped.
Low and behold, CSS Comb sorting scored the best of all the different sorting types offering a 2.73% reduction in size.
In the end, my long journey to get the SCSS Lint working and testing out these different sorting methods actually had a happy ending.