See http://csscomb.com/about/. I think the order is configurable. Sorting helps readability and it helps you find the properties easily as your eyes get tuned to where they are usually found.
It's likely to provide some help for compression (rather than minification), if you're gzipping your assets for transfer.
This is probably most effective if you tend to specify the same values for the properties as well, so that a run can extend from one property name through its value and to the next property name.
Clustering properties with identical prefixes will provide some improvement by itself, as it can keep the 'backward distance' values used in a small consistent range, but I expect that's going to be a much smaller effect.
According to the "about" page, it re-orders blocks of colour in rainbow order.
I'm starting to think of something that might be good advice in general - 10 lines of actual working example code is worth 1000 lines of abstract documentation. (I've also been working with Twisted recently, getting frustrated with documentation that's full of recursive jargon...)
This is simply about coding style and an easy way to maintain it. The home page has a link to a Smashing Magazine article discussing this. In short, easy way to maintain coding style in a team environment.
13 comments
[ 2.9 ms ] story [ 44.0 ms ] threadThat is a postprocessor not preprocessor, meaning that it works on the actual file (just like CSS Comb)
I gather that it reorders the CSS statements somehow, but I'm not clear about exactly how it reorders them or why this is important.
$default_sort_order = '[
"position",
"top",
"right",
"bottom",
"left",
"z-index",
"display",
"visibility",
"-webkit-flex-direction",
"-moz-flex-direction",
"-ms-flex-direction",
"-o-flex-direction" [...]
defined in https://github.com/csscomb/csscomb-for-vim/blob/master/plugi..., so I guess that's what CSSComb uses, although it says one can define custom orderings.
I guess it's useful if you write lots of CSS and don't want to bother with thinking about the ordering at code-time?
This is probably most effective if you tend to specify the same values for the properties as well, so that a run can extend from one property name through its value and to the next property name.
Clustering properties with identical prefixes will provide some improvement by itself, as it can keep the 'backward distance' values used in a small consistent range, but I expect that's going to be a much smaller effect.
I'm starting to think of something that might be good advice in general - 10 lines of actual working example code is worth 1000 lines of abstract documentation. (I've also been working with Twisted recently, getting frustrated with documentation that's full of recursive jargon...)
I've never heard arguments for CSS ordering as a performance issue.
It seems like removing CSS that doesn't do anything would be time better spent.
This is simply about coding style and an easy way to maintain it. The home page has a link to a Smashing Magazine article discussing this. In short, easy way to maintain coding style in a team environment.