I often find myself getting into discussions, or arguments disguised as discussions, about the preferred ordering methods for CSS properties.
Yeah. That’s how I party.
Anyway, it basically boils down to three different methods that you could follow:
- Random Ordering (because you hate yourself and others)
- Ordering via Property Groupings
- Alphabetically – aka ABCSS (my preferred method)
Why do I prefer the ABCSS method? (yes, I’m going to call it that. You’re welcome or I’m sorry, depending on how clever you find that name to be.)
Well, let’s first take a look at the pros and cons of each…
- No ordering system to learn.
- You barely have to think when writing properties this way.
- Future maintainability, you give zero F***s about it.
- If you charge by the hour, this will be quite profitable for you. As you’ll be setting yourself up for countless hours of revisiting your code and wondering what sort of drugs you were on when you first wrote it.
- If you really want to fight the other developers on your team, this will get you that much closer to your goal.
- See all the pros.
- Higher risk of duplicative declarations of properties.
- Your jumbled code in general.
- Your future self will probably build a time machine to come back in time an stab you in your face. People normally strive not to be stabbed in the face. Hopefully you can see the dilemma here.
Ordered by Property Groups
- Like properties are near each other.
- Forces new developers to learn what properties relate to each other.
- Lots of people use this method (or a form of it). In fact, it’s promoted in Nicolas Gallagher’s Idiomatic CSS
- People have written scripts to let you write your CSS how you want, and then reorder it to a grouped structure.
- You have to learn a system that can have variations to it, making it potentially different between teams / organizations.
- Since not all rule sets require all property groupings, extra documentation or comments may be needed. As without something to describe the grouping system, new developers may not immediately realize how properties are ordered.
- Stream of thought declaring requires reordering to adhere to the system.
- Many people still write their property declarations randomly within a larger property grouping, leading to possible duplicative declarations.
- While groupings of properties may become consistent, properties may still require longer scanning of a rule set to find, due to inconsistent placement within groupings and not all rule sets require all groupings.
Alphabetical Ordering – ABCSS
- If you know the alphabet, you know this ordering system. Low barrier to entry and easy to teach to others.
- Easy to see if a style sheet follows this ordering system or not. e.g. are the properties in alphabetical order? Yes? Then the style sheet uses ABCSS. Are they not in alphabetical order? No? Then you have to figure out what alternative system the style sheet is using, if any.
- Also promoted in Idiomatic CSS as an easier system to maintain on larger teams. Google also promotes the usage of ABCSS.
- Sublime Text auto alphabetizes selected properties by hitting F5 on a Mac, or F9 on a PC.
- You have to specifically NOT be paying attention to what you’re doing to write duplicative property declarations.
- Some dev tools, like FireBug, display CSS in alphabetical order when inspecting elements, making it easier to work in dev tools and copy updates back to your style sheet.
- Like property groupings: if you are writing by stream of thought, you’ll still need to break your workflow to re-order properties after you’ve finished writing declarations. You’d do this by either the method described above (Sublime reordering), or through a plug-in to auto reorder for you.
- You’ll have to write articles, or give explanations describing why this method is better than others.
I am sort of biased
OK, clearly some of my bullet points there are a little biased. But I guess that’s to be expected since I’m trying to promote the use of ABCSS over other systems.
However, I actually have used all three systems. Alphabetical ordering has been the only system I’ve found that has kept CSS maintainable across the teams I’ve worked on. In the end, my co-workers – or and those that have had rational discussions concerning CSS ordering (that actually tried it out ABCSS) – ended up coming to around to see the benefits of alphabetical ordering.
I find that when it really comes down to it, we’re really just debating personal preferences, and likely arguing on the Internet. And that rarely ends well for anyone.
So in closing
As a sole developer, you really have no reason to change whatever system you’re currently using. If it works for you, keep at it.
However, if you are going to be or are working on a team where everyone has come from different backgrounds, and each probably have their own customized ordering system to maintain their style sheets, it may be worth give ABCSS a try.
It may seem like arbitrary ordering at first, but if you let yourself get into a pattern of using it, you’ll come to appreciate that you never have to hunt for a property again.
This article was originally published at https://www.scottohara.me/article/abcss.html
17 thoughts on “Ordering CSS for Everyone”
You can scratch off one of the main cons (do this manually, learning a system) with CSSComb (https://github.com/csscomb/csscomb.js) to do the ordering for you, there are gulp and grunt plugins for it to do it at build time.
That works fine for people that aren’t using a pre-processing language to write their CSS, where the output is likely minified / not what you should be editing anyway.
And I did mention using scripts like that to help re-order rule sets. However, you may still run into situations of dual declarations if you’re just going into a rule set and writing whatever you please and depending on the script to fix your code later.
I believe csscomb supports preprocessors (sass and less, not sure about stylus) and there’s even a plugin for sublime text (and maybe another editor, I don’t know) to do it on the fly while you code. The ordering can be done in sublime without it as you pointed out, but you have to select the lines to order (is not “smart”).
This seems to me a task that should be automated, at one point.
What about using the box model as the basic organization?
Start with general layout properties like display type, position, float, clear then work closer to the actual box model like box-sizing, width, margin, border, padding. After the main box properties then font specifications and finally other things like transition, tap-highlight, user-select etc.
One of the pros seem to be – you have to know the basic layout properties, the box model, font properties and the other properties you use all day. If you can’t order properties based around the box model you don’t know them and no ordering method is going to be much help to you anyway.
Cons? The box model is not all you need. But I think it can still be useful. Works for me.
I have recently arrived at the exact same solution. Position, Box, Styles, Content.
That is a great system as long as you don’t need to worry about getting everyone on the same page, I think.
e.g. if you’re a sole developer and that works for you, keep at it.
That’s kind of the point that I was making in the grouping pros / cons though. That system sounds good and probably works quite well for you. However it may differ slightly between developers, so you could come to a situation where you have X developers on a team, and they’re all sorting ‘close’ to that way but not exactly. If code consistency matters, then people are going to have to work to break their habits to follow one version of that system.
But again, if it works for you then keep at it. Thanks for reading 🙂
This, this is my jam too.
Yup, that’s one way to do it.
Though I find issue with some of the ideas behind the grouping of properties.
color isn’t just a typographical property. It also affects ‘visual’ properties like border and box-shadow if no color is set in those.
text-align, while obviously being used for typography, can also be used to affect layout of inline / inline-block level elements.
And there mere fact there is a ‘misc’ section is just begging for (accidental) abuse.
But again, if that’s the system you follow, then keep at it.
I used to like ordering it by length, with no apparent reason. Like this: https://i.imgur.com/mAl9Szx.png
I usually like articles by Flippin’ Awesome but this is more of a rant about one person’s preferences than anything else. There’s no right or wrong way to order your CSS. If you’re a good developer and you know CSS, you learn to look at all of the properties before you change or add things. Of course there’s nothing wrong with having an ordering system (personally, I put my positional properties at the top with my @extends, everything else underneath followed by my @includes) and people naturally come about creating them, but to be dogmatic and absolutist about them is silly. If you like ordering your CSS alphabetically, by all means do so, but don’t tell people who don’t that they’re doing it wrong. I shouldn’t have a developer flip his shit at me because I put my ‘top’ property above my ‘left’ property. That’s not productive for anyone.
Maybe you missed the part at the end of the article (the last few paragraphs) where I basically said “to each their own and if your system works for you, keep at it and don’t change. But if you need to work on a team where code consistency matters, give this system a try.”
Sorry if it seemed like I was flipping out on people in this. That wasn’t the goal. The goal was to express how ordering alphabetically has worked for me & the teams I’ve worked on, and how it has the least amount of cognitive load in maintaining.
However, I’m not going to debate further with you about the pros / cons of our opinions. As I get the gist from your comment that you’ve already decided that your opinion is better than mine / anyone that may agree with me, when in fact both of ours are valid.
Take care man.
Best moment of this great article was
See all the pros.”
That was well done.
Okay, with a little more thought:
The playing field among these three systems gets a lot closer to level if you comment your code. Commenting code puts all three hypothetical developers into the frame of mine of “You have to specifically NOT be paying attention to what you’re doing [to screw this up.]”
Hi! Your post was timely as I’m working with a page of CSS that’s just starting to push over the edge into “unruly” territory.
Question: I’m buying your arguments on alphabetical CSS, but how do you handle media queries? Where would those fall in the list?
With Sass I do try to split CSS into layout regions or modules. But within each Sass file or in a plain CSS file I order by hierarchy mainly.
Comments are closed.