Over the last several years, I have read several lengthy articles on how everyone should organize your CSS and why one method is better than another. In fact, I have even bought into several of these ideas in the past, but let’s take a look at what these systems are trying to solve and why they are largely unnecessary these days.
Generally, there seems to be a slowly-fought low-emotion war between alphabetization of CSS properties and “logical” groupings of properties. The methodologies tend to hinge on readability versus reducing the risk of duplicative code and are largely written to satisfy hypothetical problems . Let’s do a quick refresher on alphabetical versus “logical” groupings.
Alphabetical
For those of you unaware (and still here), alphabetical ordering is just as the name suggests. The properties are ordered alphabetically. Organizing alphabetically is done with the idea that it is predictable and it’s unlikely you’ll have duplicate properties.
Example:
.alpha {
background: #fff;
color: #333;
font-size: 1rem;
font-weight: 300;
left: 0;
line-height: 1.5;
margin-bottom: 20px;
padding: 0 20px;
position: absolute;
top: 55px;
width: 70%;
}“Logical” groupings
This is the category I have leaned toward in the past. It allows people to group things together in a way that is logical to them. Keep font stuff together. Keep positioning stuff together. Keep animation stuff together. You call it.
Example:
.logical {
background: #fff;
position: absolute;
top: 55px;
left: 0;
margin-bottom: 20px;
padding: 0 20px;
width: 70%
color: #333;
font-size: 1rem;
font-weight: 300;
line-height: 1.5;
}Neither are better for any reason
Yep. Spoiler. Neither matters all that much and you can use every method on the same project without the universe imploding. Time to debunk some stuff!
Ease of reading
I think we can all agree that alphabetical isn’t perfect. It’s starts to get pretty funky when you get into absolute or fixed positioning with various authors making various recommendations. It’s also only super quick to skim when you know what property you’re looking for. It’s also not super intuitive to gather all the font or box-model properties to see what’s going on.
Most “logical” groupings (even ones in different orders with different conventions than ones I regularly use) are straightforward to read. There aren’t too many problems. Usually people get positioning, box model, and typography properties grouped nicely even without training. Heck, at this point I would recommend not even bothering to stress too much where things go. Let people do their own thing. Worst case scenario, you have to skim through fifteen properties. More realistically, though, it’s usually only a couple.
But none of the above matters. Ease of reading is a straw man argument by me. It’s easy to knock down because all that matters is the easy of finding a property. This is just as easy with either method and more often than not, in my experience, starts in the browser. Yep. Digging through inspector where all of our sweet line breaks and comments get reduced to a single list, but once you find it there, you can hope to the file and modify your property. You don’t even have to look that hard!
I have one more minor point to make about readability: Most of the time, property lists are short. We’re talking two to six properties. Both methods often end up looking and operating just fine at that length.
Reducing the risk of duplicate properties
Use a linter. Seriously. We have tools that pay attention to this so we don’t have to. Alphabetical is still suspect to minor duplicative properties unless you eliminate shorthand properties like the following.
.duplicate-line-height {
font: 15px/20px serif;
line-height: 1.5;
}
In addition to a linter, implement a code review process on all code. Even just one extra set of eyes will catch these things. Not only that, but you’ll grow much quicker as a developer when you implement a good code review process.
The takeaway: Do what you want
I get it it. You’re passionate about things and like them to be predictable. So do I. It’s satisfying to write that way, but it turns out, it’s not essential to writing really beautiful CSS. Use multiple patterns in your project if you want. Encourage people to try different things with their property ordering. Some might work. Some might make you cringe a little, but relax. You no longer have to stress about keeping everyone’s properties in a single opinionated order. You can do yours exactly how you want and they can as well.
There’s an additional benefit to mixing it up. When properties aren’t in a predictable order, you actually have to spend a little time reading them. Don’t worry. We’re talking additional seconds, not minutes. Don’t panic. More often than not you’ll end up improving on code you never would have seen if you just skimmed down a list for your desired property.
What do you think?
Have I gone mad? Am I way off base? Is this going to be nightmare-fuel for you (I hope not)?
I might be an odd duck, but I’m doing something that apparantly noone ever does: Logical groups … and chaining then within a line.
I write my css like
.logical {
content: 'Hello World';
position: absolute; top: 55px; left: 0;
width: 70%; margin-bottom: 20px; padding: 0 20px;
background: #fff; box-shadow: 0 2px 4px rgba(0,0,0,0.25);
color: #333; font-weight: 300; font-size: 1rem; line-height: 1.5;
}
Content first, then positional properties, then dimensional, then box styling, then text styling. Although I must admit I’m not as strict anymore when it comes to properties that are more exotic, they are usually going in at the bottom. And when it comes to ordering the properties in a chain, I go by the order of the respective shorthand. That allows me to easily compact
font-weight: 300; font-size: 1rem; line-height: 1.5; font-family: serif;
into
font: 300 1rem/1.5 serif;
if I so desire. Same with properties that are sorted TRBL in the shorthand, like margin and padding and border.
As for the “use alphabetical like everyone else” argument … really? If you are used to that and have to take over some work that uses logical grouping, that’s a trivial problem that can be solved with a simple run of CSS “beautifying”. No need to scream at other people.
I can see the logicality of this, but I find it very unreadable.
Different strokes, I find alphabetic truly horrible to read. Also, usually the only one who has to read it is me. If someone else takes over, he’s free to (auto-)format it to however he/she fancies.
For better or worse, this style will create more merge conflicts than having each property on a separate line.
I partially agree.
I tend to do some form of logical grouping, for example: I line up values of properties whose values should be the same:
.fullscreen{
position: fixed;
top: 0;
left: 0;
right: 0;
bottom: 0;
}
Notice how the same values are in the same column. I could alternatively use a CSS or pre-processor variable, but to me this is quicker and immediately lets me know that these properties should have the same values. It’s important to identify when properties should have the same values and when it’s purely coincidence. A major downside to this method is it’s more time consuming because I have to space each value evenly.
Anyone tried CSS Comb? You can use it as a plugin for sublime or in a task runner. http://csscomb.com/
Yes actually, I find it great.
I use the order below:
https://pastebin.com/uTUrpzax
When people say this stuff is subjective it’s really not. There are studies out there about the usability of different sorting mechanisms albeit not specifically related to CSS properties. Those studies can still provide objective measures. The choice of using grouped or alphabetical is subjective in the sense that people are only using anecdotal information to back up their choices. They’re not taking a look from a usability perspective, setting tasks, measuring error rates and coming up with any quantitative data. It’s conjecture based on how they feel or their personal bias.
That’s not necessarily to dismiss how they feel, since expert review is a means of discount usability testing. However, we have to understand the limitations of expert review. Sometimes they don’t shine a light where we need it.
One thing I don’t see much discussion of is how either of these systems impact different types of users. For instance the people making the arguments are highly skilled domain experts. The sorting they use works within the specific context of their respective environments, which may be very different from one another. You have domain experts who largely work alone or in small teams with good control over their code, those who work in a highly automated fashion and have generators and utilities to maintain code quality, and those who work in larger teams spread across a very large organization who may have limited oversight and limited automation. You have some people using CMS tools for authoring, some developers using Notepad, and then still others using Visual Studio Code packed to the gills with every linter and code beautifier under the sun along with an autocorrecting eslint checker built into the Continuous Integration environment. These are all very different contexts with different needs.
Large organizations can often employ lots of people with low domain expertise (I.E. the best Java developer they have working on the UI because he used JSP once). In these types of environments turn over is high and domain experts are often stretched thin. However well grouped and logical the code is to a domain expert it can still appear to be random to a non-expert. In those cases the non-expert will not see the inherent order in the code and will simply drop a new property in wherever. This can still happen within alpha ordered code, but it’s much more readily recognized and caught by novice authors than an error in logical grouping would be.
Since most orgs aren’t going to do a usability study to figure out if they should order their properties. I think it’s at least important to make sure they’re fully thinking about their users and their context holistically. There are developers, designers, content authors, random business persons, and sometimes code goes through multiple roles before making it to the end-user. Sometimes the person in prod-support is not the same as the person who wrote the code. We have to understand these roles and context and choose the methods that work for all of them. Don’t let it be a free for all, that causes too much confusion and leads to finger pointing when things go wrong. Pick one, pick both, train it if you need to, but do so because it makes development go faster with fewer defects and lower cost of ownership.
Whatever you do, please be consistent.
I very much like the frame around the page! 🙂
While I preach alphabetizing, I emphasize personal/team preference. Your points are right in the money.
Personally I order some properties logically – eg. font-weight, font-size, line-height together and position, display, top, left etc. together. Also margins together, padding together
But beyond that it just ends up random
I think you are missing the point of alphabetising. It’s not to avoid duplicates – there are tools for that, as you point out.
Is to avoid the extra mental effort to have to remember which “logical” group a property belongs. Some of them are obvious, but some are not. Also the order in which groups appear must be remembered. And of course there is nothing universal about it, it changes from team to team, project to project. With alphabetical order there are no such problems – you know exactly where everything goes, without thinking.
The only issue used to be vendor prefixes, but thankfully we have tools for dealing with that nowadays.