Eric, again not mincin’ no words with blog post titles. This is me:
The most common CSS declaration organization technique I come across is none whatsoever.
Almost none, anyway. I tend to group them by whatever dumps out of my brain as I’m writing them, which usually ends up with somewhat logical groups, like box model stuff grouped together and color stuff grouped together. It just… hasn’t mattered to me. But that is strongly influenced by typically working on small teams or alone. Eric recommends the alphabetical approach because:
[…] it imposes a baseline sense of structure across a team. This ask is usually enough, especially if it means cleaning up what’s come before.
And his (probably bigger) point is that the imparted structure helps legitimize CSS in a world where CSS skills are undervalued. Not going to argue against that, but I would argue that hand-alphabetizing CSS on an existing project is very likely not a good use of time. Worse, it might break stuff if done blindly, which is why Prettier punted on it. If you and your team agree this is a good idea, I’d find a way to get this into an on-save function in your code editor and make it a pre-commit hook. Alphabetizing is a task for computers to do and the output can be verified as you are authoring.
VSCode has a command for that: Sort Lines Ascending.
Just bind it to a key, select the declarations and sort them. It’s semi automatic but you don’t have to update the whole project.
It’s probably I who’s missing something :-) – but is something missing in this article?
This is just refering to “ABCSS” (alphabetical sorting), no?
I’m asking because that is so old. (CSS Tricks is usually new :-)
I googled and there are many people who wrote about it earlier:
On Declaration Sorting in CSS (2014)
Alphabetize your CSS properties, for crying out loud (2017)
One Simple Rule to Organize Your CSS the Right Way (2019)
What makes Eric special?
Suggestion: an article about the history of CSS sorting with credit to all these people?
I may be wrong and/or out-of-date but I have a feeling that alphabetic CSS rules get parsed faster too. Not in any meaningful way, we’re talking milliseconds tops, but if you need a way to justify doing it to your boss you can leave out that detail :D
Source on this? Based on what I know about parsing, this doesn’t sound right.
Alphabetization feels right, but it can actually have a negative impact on GZIP/Brotli compression ratios by shortening the length of repeated segments throughout the document.
For example, most people following a simple brain-dump sort of approach will naturally group logically-related rules together, like width and height or margin and padding.
In a given stylesheet, the chances of multiple blocks sharing the same width and height — e.g.
width:100%;height:auto
is pretty good. Encoders will pick up on that and tokenize the entire pairing.But if you alphabetize everything, such common pairings only remain common pairings in classes which have no other definitions between H and W.
Exactly what first poped to my mind reading this!
As mentioned in passing, this is dangerous to do automatically since the order of CSS declarations affects which one gets applied. How often have we done something like this?
What if alphabetizing those two lines results in the order being reversed from what it is there? Can we confidently say that that will never be the case? Is there no alphabetization algorithm in the world that sorts the minus sign first?
It just feels like far too fragile a thing to rely on to leave to automation. ¯_(ツ)_/¯
My thought too. At first it sounds nice, but since CSS is cascading, you might be forced to have some declarations non-alphabetized.
How about this..
animation: spin 2s linear 3;
-webkit-animation: spin 2s linear 3;
Hopefully code like this is never the case!
ordering declarations alphabetically is total mindfok, i don’t event wanna start thinking about cascading and implication of the sorting choice…
I tried to go with the alphabetization approach on a large project, and one big problem I’ve found with it is that it often leads to difficulty when reading the code again, because your eyes have to jump across the ruleset to try to figure out what the cumulative effect may be of a number of interrelated properties.
Like,
align-items
is meaningless apart from a grid or flex, and with alphabetization, there are the other As as well as B and C properties between that anddisplay
. So as I, or someone else on my team, look through a ruleset, I just feel like there’s more cognitive overhead keeping track of which properties act in tandem together to achieve a certain effect.The convention I’ve landed on is to roughly list properties in order of dependence or relevance.
display: flex; align-items: center
, orposition: sticky; top: 0
(even though that one’s alphabetical lol). I also group things likeanimation
andtransition
together, since they’re related yet separated quite far from each other in the alphabet. And I’ll often even keep the properties that are changed by an animation or transition close by, such astransform
oropacity
.I like your idea of just listing things as they kind of dump out of your brain, because I think the brain kind of naturally organizes by order of importance. “Oh, I need a flex container with space-between justification and a gap” ->
display: flex; justify-content: space-between; gap: 1rem
. Way out of alphabetical order, but much easier for the brain to understand in a more scaffolded way when reading back. At least imo.Personally I don’t like alphabetical ordering, since don’t like the idea to split certain properties that should stick together.
But do get why I helps in teams as it adds more consistency.
Luckily in my team we follow the box model order. It’s explainable to others in my team and to newcomers since the browser is your cheat sheet.
Have we considered Awesome style lint yet……. It does a whole ton of stuff and you can even regex your own pattern so that padding-right never comes before padding etc
I don’t think it’s a good idea. I think we should organise our css section wise. Because it would be easier to clean your css if you are removing some of the sections. Otherwise you will need to find the classes one by one or you will go with unused junk css. It’s not a good idea at all. There is no use of organising css alphabetically. I feel it’s completely useless
No, no, no! Grouped order is much better eg. this one
Consideration needs to be given to the the fact that in CSS, for rules with the same specificity, the order of declaration affects the output. It may be for the best that your CSS can run in any order–but still, part of the cascade IS the declaration order.
So while alphabetizing style sheets may make them easier to sift trough, it may also put a lot of other, possibly unnecessary, constraints on how you declare your selectors, HTML, or even name your classes.
Follow up article: how to logically name your classes.
As I have a blogpost in the drafts-folder about this very topic, here’s my little list of the benefits of using alphabetical order. Note that this is written from someone working on a large codebase, with 15+ developers contributing continuously to said code.
Democratic: Picking alphabetical order means that someones arbitrary preferences doesn’t get picked (See also the last point below).
Consistency: Using the same order across the entire codebase makes the code predictable, and makes it easy to find specific values once you learn where to look.
Easily automated: If you are using Stylelint you can enforce the ordering with the help of the stylelint-order plugin. And there are ways to tie ordering to shortcuts in both VS Code and Webstorm/IntelliJ.
Easy to grok for new colleagues: Related to the first point, applying the alphabetical order helps onboarding new colleagues since most people know the alphabet by heart. With most other sorting schemas, you would have to memorize it which would add to the cognitive load.
No/less bikeshedding: Most other sorting schemas involves varying degrees of personal opinion(s). After the initial work of setting up rules for which properties are grouped together, and what group comes first, you’d have to revisit that meeting every time a new property (or group of properties) gets introduced to the codebase. And if you are more than a few developers on the team, chances are that old decisions on order might get thrown back on the table for reevaluation. With the alphabetical order, there is no need for such discussions since the order is decided by something universal and outside of the developers hands.
At first it might feel a little weird to rely on something that is not based on something you’ve decided yourself, but much like adopting Prettier, once you’ve settled for it it is a bliss to not have to think about or reason about the order of properties and let the tool handle it for you.
While grouping logically related selectors feel like the obvious choice (and believe me, it does feel weird to put
align-items
beforedisplay
) and while the way we group easily can be made into a rule of sorts, such a rule would still be highly opinionated and still leave lots of room for interpretation and misunderstandings (”Why isn’t the box model group first?”, ”How do we sort individual properties inside the groups? Or maybe we don’t?”). This is of course fine if you are deciding this for a personal project, or for a project where the number of contributors is small and the developers have a homogenic view on how it should work. But for larger projects and enterprise applications where the number of developers are higher and the codebase is to be maintained for a longer period of time, questions like these add up. And while it might seem like an important decision at first, you really don’t want to have the same discussion over and over again once you’ve settled on a solution.In a perfect world I’d go for logical grouping. But since… you know (waves frantically around me), my pragmatic approach is to opt for the second best, which is alphabetical ordering.
I like the way chrome devtools groups properties in the computed style panel; Layout, Text, Appearance.
I’d always done something similar before people started telling you to do this or that.
As a freelancer, every project nowadays is adapting to someone else’s take on every keyboard tap, pull request, too many/not enough comments… Yawn.