Regarding property ordering, I have to disagree that alphabetical is the sensible route. My ordering might seem strange, but the properties are grouped and ordered by relation to one another. Given the following example:
.element {
box-sizing: content-box;
color: blue;
display: block;
font-family: "Open Sans", sans-serif;
font-size: 13px;
font-style: italic;
font-weight: 400;
padding: 30px;
width: 100px;
}
You can imagine the author’s expectation would be for the .element
to render with a width of 100px, but because box-sizing: content-box
is present, the width is actually calculated as 100px plus the 30px padding, totaling 160px.
This may be an extreme case, but it illustrates the problem. By grouping related properties (box model/layout, font properties, visual styles, etc.), it’s more obvious to authors what properties are affecting one another. The above example could be written like so:
.element {
box-sizing: content-box;
display: block;
padding: 30px;
width: 100px;
font-family: "Open Sans", sans-serif;
font-size: 13px;
font-style: italic;
font-weight: 400;
color: blue;
}
Yep, that ordering is totally fine and good when working alone, or with someone who shares your views, or with any finite non-changing set of people. But, in a dynamic, evolving team environment, non-alphabetical ordering creates friction and possibly a bad Developer Experience :) In contrast, you don't have to teach anyone how to order alphabetically. They don't have to learn the ordering – it's alphabetical. There's no friction. Like, if you jump into someone else's CSS, it's so much easier to see if a property is already declared or not: just browse through the list alphabetically :) Other than that, I think your method is sound and no harm doing it. Just make sure you aren't forcing others learn things they don't need/want. Empathy!