Over 10,000 people have spoken: the most popular way to order CSS properties is grouped by type.
This is how the votes broke down:
Grouped by type (45%) was fairly closely followed up by Randomly (39%). Much less popular was Alphabetic (14%) and only a few folks using Line length (2%).
For the record, Grouped by type would be like this (heavily borrowed from Nicolas Gallagher’s Idiomatic CSS):
.selector {
/* Positioning */
position: absolute;
z-index: 10;
top: 0;
right: 0;
/* Display & Box Model */
display: inline-block;
overflow: hidden;
box-sizing: border-box;
width: 100px;
height: 100px;
padding: 10px;
border: 10px solid #333;
margin: 10px;
/* Color */
background: #000;
color: #fff
/* Text */
font-family: sans-serif;
font-size: 16px;
line-height: 1.4;
text-align: right;
/* Other */
cursor: pointer;
}
It probably wouldn’t be specifically labeled with comments like that, but the properties would be next to each other.
The majority of folks are more organized than me! I regrettably had to vote “Randomly (no specific plan)”. I don’t feel like it hampers me that much, but then again, how would I know if I don’t try out a more organized approach?
I have a few other thoughts.
I think this is a bigger deal in teams. There has to be a standard otherwise the CSS project-wide looks sloppy. I know that inconsistent styles would wear on my conscience and I’d spend time fixing trivial formatting stuff rather than doing actual work.
Cognitive load factors into this. If you can always count on certain properties being in the same place, you can understand the CSS a bit faster (less scanning). Again, a bigger deal when on a team and you are looking at code you are slightly less familiar with because you didn’t write it.
Another consideration is “as you originally write it” CSS and “after a few months” CSS. I bet a lot of us start out with the intention to be very organized and actually do start organized, but then as you tweak things later, toss properties wherever. So then how did that affect the vote? Did you vote based on your intentions or your actual CSS files?
I don’t know, man… I just think going alphabet is a lot easier to maintain (for me). Plus, firebug for FF alphabetizes and I copy and paste a lot when I’m designing/tweaking in the browser.
Not just for you, but also for big teams. Alphabetical order is the simplest way to minimize time lost searching for properties as everything sits in a recognizable order, and team members don’t have to learn (and remember) a ‘grouped by type’ based order.
Very interesting subject Chris. I personally am part of the 2% who group the properties by line length. Not only using this method gets you a smaller css file on disk, but I also find it faster to identify styles and to navigate inside the stylesheet when making edits after a period of time, because it saves you a lot of scrolling.
I ask you, how many times did you manage1000 lines stylesheets formatted using grouped by type method.
Wouldn’t it have been better to only manage 300 lines of code instead?
How does grouping properties by line length give you fewer lines and take up less disk space? I would think
takes up the same space as
Jamie, I believe that Andru is actually referring to this:
I am of the belief that having to scan both horizontally and vertically will decrease efficiency, and if you are minimizing your code when publishing then it won’t matter how many lines you take up when writing it.
With cmd + f it shouldn’t matter and as Josh says, looking both horizontally and vertically will decrease rather than speed up, I know whenever I create an HTML Email it takes the piss looking for all the inline styles.
In addition, it shouldn’t matter how spaced out your code is because for the live site you should be optimizing anyhow.
Jamie,
Josh is correct about the way I format my css. The thingy rule that you wrote takes you 19 lines of code (assuming you leave one empty line between each property), while for me it takes 1 or max 2 rows depending on screen width.
For me is much easier to follow a code formatted this way, as I don’t have to scroll at all while editing the rule. I also have to visually scan a far much smaller area to identify the parts I need to change, but this is a personal preference.
Each coder writes his css in a different manner according to his own style, so I believe that there isn’t a best way to do it. It’s more important what code you write than how you format it.
Hi, first comment here, but I did vote, and I voted Grouped by Type.
But that’s more of a “good intent”, sometimes even wishful thinking. I group them when I start writing them. Then I add more, and it ends up pretty messy. I should try the comments.
But then, I’m not a pro, so it’s just me hating myself when I come back to the code after a few months ^^
Some poll ideas:
Where do you work?
-Company Office
-Co-op Office
-Home/Remote
When you search for CSS syntax, what website do you use most for results?
-css3please
-MDN
-css-tricks
-W3C
-Sitepoint
-w3schools
-whatever the top google result is
-i actually use a printed book
Which would you consider the more advanced CSS skill?
-Page layout
-CSS3 Animations
-CSS Preprocessors
(not sure that last one makes complete sense, since knowing how css works is kind of a prereq to preprocessors, but maybe something like that….)
Alphabetical or GTFO. Everyone is going to have a slightly different concept for ordering and grouping, which has to be explained to every new person working with or looking at the code. Alphabetical ordering doesn’t need explanation, assuming you got through elementary school. Sure, it doesn’t look as pretty and it might take a little getting used to if you’ve had bad coding habits in the past, but in the end, I’ve found I’m faster and more efficient when creating and revising CSS using an alphabetical ordering scheme now that I’ve become used to it.
I don’t quite agree with this because while people will interpret groups differently, just about anyone with that same elementary school education would figure out the convention in about 30 seconds. Plus, it shouldn’t be a surprise you are faster and more efficient with a system you’ve become used to :)
Alphabetical is the only system I’ve found to work reliably in teams, not to mention it makes auto-sorting possible. When I’m just banging code out, testing various approaches or whatever, I often don’t bother to order the selectors, but before it gets committed (because if you’re not using a VCS, we need to talk), I can run through it with a sort command and oh look, my CSS adheres to a coherent system! If you can teach your texteditor how to group by type, I’m impressed.
I agree. It’s much more easier to maintain and easy to get.
Josh, alphabetical order removes the potential for ‘group by type’ mistakes that can be made. Enough of these little mistakes, along with the time required to learn the groups (and order within the groups), makes alphabetical order easily the most efficient.
There are a couple caveats to alphabetical order.
The first is that vendor prefixes need to be grouped together:
The second is that css preprocessors throw a wrench in the concept of ordering properties when mixins are used:
My tendency is to mix in (no pun intended) property-based mixins alphabetically, such as
.box-shadow
or.border-radius
.Any multi-style mixins appear above or below the list of properties depending on which styles need to take precedence.
Personally I prefer alphabetical ordering because there’s little ambiguity and faster to teach than a custom order which is easy to mess up.
I like going with “type” as in CSS many properties have a strong relationship, for example
position
andz-index
.If a rule evolves and the element is styled as
static
, then there is a good chance thez-index
declaration will not be cleaned up unless those 2 declarations are close to each other.@Thierry Koblentz Exactly this.
Ordering by type is the only way to assure that you don’t forget about certain properties that are closely related when you make changes in your CSS.
Also, it doesn’t make any sense to me to separate positioning properties such as
left
andtop
.Absolutely. Mind you, I don’t work in a team, so I have the luxury of being able to work as I please. But sorting by type allows me to see at a glance what the CSS is doing.
Here’s the problem with sorting alphabetically: if I don’t know what properties are in a declaration, I will have to look through the whole list to see everything that affects, for example, layout. Group them by type and I can ignore most of the properties and just focus on layout or type or whatever.
This, along with something Chris said.
I will always, ALWAYS prefer to see top and left together (or bottom, right, whatever ones you’re using). Anything else is insane. Problem would be solved if there was a common prefix like “margin-” and “padding-” have, but alas that is not the case.
So, I group loosely by type. Which brings me to what Chris said: get back to me in a few months and we’ll see if it was maintained. ;-)
As per other comments, I also feel that so-called “consistency” in the approach doesn’t matter, EVEN ON TEAMS. As far as I’m concerned, it’s more important to use the cascade properly, and if you’re doing that it will be rare that you’ll see a style with 20 different properties. And even when you do, how hard is it to scan 20 properties and find the one in question? Not hard. To be honest, even the “top/left” thing wouldn’t truly be the end of the world even though I think it’s insanity to separate them.
Yeah, what @Anthony Nichols said. :)
Grouped by type or GTFO. I find it very easy to go back and my code and say, “oh this block right here takes care of the box-shadow stuff,” which is very nice when dealing with vendor prefixes. Sometimes I do try to have alphabetical order within the type groups, but that’s when I’m not under a time crunch.
I prefer a form of grouped by type as well. Alphabetical is just silly… why should height come way before width? That is counter-intuitive. In my brain, it makes sense to have width followed by height since that is how a majority of dimensions are read aloud in English. 200×150 = 200 width by 150 height.
Same can be said about margin and padding. They should be next to each other, and near the width/height rules, since the four of them together are what will give you the final dimensions of your element.
A lot of these initial comments have a call to alphabetical order, but a lot of this talk makes it sound like you have like 40 style properties for any given selector. I mean, unless all of the styles aren’t fitting on one screen view (ie taller than your editor), that’s the only time I see ABC being all that superior to grouped, and if that’s the case, you’re doing something wrong.
I also would be curious how people handle preprocessor mixins and nesting. For example, I try to pull in all mixins first, and always declare all the styles for the current selector before nesting an element. That seems pretty basic as it would be kinda crazy to separate styles of one selector by a bunch of nested stuff.
Also, I’ve been working on not nesting too much (ie on a single tier nav, I will put ul, li and a at the same depth level).
This brings up a very good point – since I have started using a CSS preprocessor (SASS) and incorporating concepts from OOCSS // SMACSS, the once monolithic CSS classes with numerous styles properties have shrunk down considerably. This modularity affords quite a bit more logical organization and extension of previously declared styles, without having to worry about alphabetical / grouped order.
To touch upon some other comments – individually I hardly see how it matters what ordering concept you use, outside of your personal preference. In group coding environments, having a common ordering cypher saves time. Time is money. It takes far less time to explain “Alphabetical.” than it does “Well you see, we do box model first, followed by positioning, then color…” etc.
To be perfectly honest, I’d prefer a logical grouping structure, but only if it were a standards-enforced, widely-accepted order that was agreed upon and could be easily memorized. I can’t tell you how annoying it is to have “height” come before “width” despite dimensions being “width x height,” and other similar circumstances.
I think the best way is random, as we always do things a little hasty.
I used to be a real goof and sort by property name length combined with a colon-based tab stop (which I manually maintained). Like this:
For a while, that looked great, and made it easy to scan down for specific values, because the values were aligned, and I knew exactly where to look for a specific property because I knew the name length. It felt faster than alphabetic, usually. But I spent 4 times as much time re-spacing everything to make the colons line up, every time I added a longer property name.
I tried grouping by type, but that’s not consistent. As an example, in the above, you show “Positioning” and “Box Model” as two sections. This makes “margin” a difficult property. With a value of, say,
10px
, margin fits into the box model perfectly. But when you assignmargin: 0 auto;
you’re now using that for positioning.What I’ve recently switched to, is separating out layout from color and typography. One CSS file dedicated to layout (which makes it easy to handle responsive designs. A second CSS file dedicated purely to color (border colors, background, text color, etc). I actually run this second one through a preprocessor sometimes (example, colors.css.php) and then I use PHP variables so that I can assign colors more easily using named variables. Then lastly, a typography CSS file dedicated to fonts, font sizing, and other typography related items such as line spacing, text alignment, and even in some cases, padding and margin (particularly for paragraph elements, which are used for copywritten blocks, not layout blocks).
I find this makes it really flexible for having responsive designs (colors.css.php hardly needs to be modified once made), and only a few minor tweaks to the layout and typography are needed when new devices are factored in.
When you are under SCM, such approach will lead you to commit actually unnecessary changes due to constant reindenting.
Hi folks, writing CSS code is one of the most important tasks to design a good website, project app, etc. I think when you write code clean the result will be the same.
I usually order CSS as follows:
.selector{
/* Color values */
/* Box model */
/* Text elements*/
/* Border style*/
/* Animations*/
}
I also prefer alphabetical formatting. It helps me a lot, and I avoid writing the same properties twice. Sublime text 2, makes it very easy to move properties up and down.
I use sorting CSS properties in specific order http://csscomb.com/
I personally group my CSS properties alphabetically as I feel it helps us to analyse large amounts of what is essentially linguistic data by utilising human cognitive working memory.
Our working memories are trained to know how far (roughly) letters are “spatially” apart from one another in the alphabet, so when it comes to searching for words in CSS properties we know that when we are looking the “border” property, it is going to appear near the beginning of the properties declared and “top” is going to appear somewhere near the end.
Naturally this is something which people whose first language is a western language will probably find works better, than for someone whose first language is not.
Incidentally alphabetical declaration is something that Google use in their Google Code CSS coding standards.
In most cases, I go full random with CSS properties, since I generally do it and not get back to it on small projects. Moreover, it would take me more time to classify CSS properties than searching for the right property if I have to edit the file.
But on larger projects, I prefere alphabetical order, because it’s clear and universal. Even if I have to get back to the stylesheet after months, I will immediately find what I need.
But I understand the grouped by type method, it makes sense, really.
Further more to my original comment I split my styles out into what I refer to as template styles (ie: styles concerned with layout, positioning and size of elements) and stylistic styles (ie: styles concerned with how elements “look”). The idea being I should be able to remove all stylists CSS rules and nothing should really move on the page – simply just become unstyled.
This serves two functions, it makes it easier to debug styles as it reduces the amount of lines you have to read through – as typically you know whether the problem is concerned with layout or design, and secondly it makes it easier to change the stylistic design of a site and whilst not affecting its layout and vice versa.
In addition to this practice I have also adopted using SASS now for doing my CSS, which makes it really easy to separate styles in this way, because the compiled CSS will be the result of the template being imported into the style .scss file at compile time. (As well as all the other lovely goodies SASS provides.)
Personally, I find it a non-issue alltogether. Any standard in this area, or lack thereof, is easy to comprehend.
I’d say first worry about your CSS “architecture”, as in balancing reuse and semantics, modularization and pre-processing. You can sweat the details of trivialities like this once you have reached that point.
Personally, I like “group by type” because it makes your CSS styles match what they’re actually styling. It’s a reminder of how the positioning/box model affect what my styles do. Furthermore, it keeps things I’ll likely work on at the same time together. For example, If I’m working on a layout issue, it’s nice to know that all of my layout and box model styles are together; I can easily work out how the width, padding, borders, and margin are affecting each other and the layout. If I’m dealing with a text issue, I can see all of the text stuff together, and figure out quickly whether extra bold font is a font-family issue, or a font-weight issue. I like not having to mentally filter out things that don’t apply to what I’m doing right at the moment. By being able to just see everything I’m working with on a related problem together, I can much more easily avoid the noise.
Wow, I’m really surprised that Alphabetical doesn’t have a higher percentage. Very interesting.
Most of the comments for ‘group by type’ seem to be by those who may not have worked in larger teams (obviously this is just an impression, not fact). As such, the result may be biased to those that work alone.
In terms of your individual style, it really makes no difference to anyone else. Whatever you are most comfortable with will probably be the fastest way for you to code. It’s when talking about teams that it begins to matter.
Voted for random myself, perhaps I would have liked to have fitted into a slightly different category. Random just kinda sounds like my brain is all over the spaghetti sauce… fact is, I create each as the need arises, and things just tend to develop and keep their own order I guess.
Everything else just sounds a touch too anal me thinks.
It might have been interesting to have each of the respondents categorize themselves as, “designer” or “developer”, or… eh, both.
Interesting poll though, thx!
Yeah! – just to follow-up on my own post.
Date/Time Order would best describe my practice.
Shit! I must have too much time on my hands at the moment, ya got me thinking ’bout this.
Date/Time Order is not quite accurate… (preferred) Creation Order might be closer, coz if I am onto say [.generalcontent #colright p{}], and I discover a need for [a img:hover{}] I will go back and insert at the top.
Make sense?
Preferred Creation Order, has my final vote… for the moment anyway! – it’s all about my own on-going learning.
Thx again, I will shut up and listen now :-)
I tend to list properties randomly, but I’ve been meaning to try some form of organization. Looks like I’ll be trying grouping by type!
I order alphabetically but I also separate them by CSS3 and CSS2 groups.
Hi Guys.
I think that CSS2 and CSS3 styles separation mentioned by Sung Choi is very important thing.
It’s very annoying when you try to change anything in messed code like below:
It looks like green code from “Matrix”.
As for me I try to keep styles with “-webkit-“, “-moz-” etc. after simple CSS2, for example:
So it’s very easy to find necessary styles and change them in such structure.
I have always just done random but there tends to be a theme usually because I often just think of properties in a certain order. That said; after reading this poll I decided to try alphabetical as I feel it makes the most sense universally.
It has been hard for me to follow so far as habits are hard to break but it has certainly been easier with editting and finding properties.
Thanks for the poll tho.
I group alphabetically but I put the one with vendor prefix at top. I think it is easier to look at. Now that I am using SCSS, i put the one with @include at top.
Do what ever is comfortable for you but if you are working in a big team or big portal then I suggest Grouped style.
Because we can avoid some sort of missing when someone searches style for further modification. They can very easily search and edit the portion they want to edit. No need to search a lot in all styles in each class. They can very easily find the area from each class if we grouped the style? Anyway thanks to Cris for took a good poll.
I Order my CSS with the type and in that alphabetically….
It will save my lot of time at the time of editing and searching any code…
Very interesting results. Sometimes I order the CSS by type and sometimes it’s random, depending on how much CSS there will be and what it is for.
Great poll with interesting results.
I generally I find myself grouping by type although I don’t actively try to group it.
I could never imagine sorting by line length although sorting alphabetically seems to be the easiest, clearest and most consistent option when dealing with teams.
I can’t believe that 2% do sort by line length!
Alphabetically all the way.
Normally I order my CSS like-wise to the order of elements.
First I plce the “global css”. Like html, body, form elements, etc…
After that I put the elements in order of appereance in the webpage code.
Example:
#header{}
#menu{}
#content{}
#footer{}
I think the survey is talking about the order of the properties. For example:
Interesting. I order my css properties by order of html elements. I mean, I start with html, body, wrapper following with header, next content, sidebar, footer and then media queries or some extra stuff.
This is what Chris means by properties (you might be talking about selectors):
looking at this post I suggest to have a look at
I just found it and seems built for this kind of polls
Mine was always random until I read this. Sometimes I sorted alphabetically.
I love the idea of grouping by type, and grouping alphabetically by type, but at the moment I’d spend more time reordering my CSS properties than I would writing CSS, so it’s not very efficient for me in the short-term to organise them in such a way.
Maybe it’s something I can do after I’ve finished writing it all!
Didn’t vote, but would’ve voted “random”.
As I like to put all properties on a single line, grouping and ordening doesn’t really help me much. With one line/prop, I think the grouped option looks best.
I like to write my css code as i go, but every now and then put it through a css formatter program. So if i have to change something then finding it is easy, but at the time i can just hammer out code, also means its alot more maintainable for me and others when comign back to change stuff.
When I’m first writing the CSS it’s just about always random. But before the site goes live I usually try to group by type, mainly just because I like to have clean CSS the next time I redesign or use code from that website.
I really think that “by elements order” should be a option.
I’m real surprised that alphabetical is so low. Google recommends using it in their front end guidelines.
Do you have a link to a copy of their guidelines?
The order-by-type method lets you easily visualize how the object is to be rendered, visually organizing the rendering from outside, in. It’s especially useful since the width and height are affected by the previous properties. This makes it easier to spot where a layout problem might be found. Listing the clutter of CSS3 at the end also keeps the details visually easier to read.
Actual Selectors – I organize those by group – what all goes with the header or footer or a given page element.
But as for the properties for a given selector – that ends up being random.
Hate to admit, but I use randomly. Sometimes I go back and organize into groups that pertain to each other.
I order properties within a declaration block similarly to the order of the box model. 1. Content (Display/Position, Width/Height, Background, Font, etc. 2. Padding 3. Border (Decorations: e.g., border-radius, box-shadow, etc.), Overflow, etc. 3. Margin and other (e.g., cursor, transition, etc.)
Errata/Correction: 1. Content (Display/Position, Width/Height, Background, Font, etc. 2. Padding 3. Border (Decorations: e.g., border-radius, box-shadow, etc.) 4. Margin and other (e.g., overflow, cursor, transition, etc.)
I just created
with some different possible answers considering the comments in this thread
That survey pertains to selectors, whereas this one deals with properties.
My opinion, it’s less about how the rules are organized and more about how the entire document is organized. We all use single line CSS here. So scanning is top down, then left right. Getting to the rule is more important then the order of styles within the rule.
body {margin: 0; padding: 0; font-family: Verdana, Arial, Sans-serif;}
p {font-size: 12px; line-height: 140%;}
a {text-decoration: none; color: #369;}
.clear {clear: both;}
.right {float: right;}
.left {float: left;}
#wrapper {width: 80%; margin: 0 10%;}
#head {height: 100px; width: 100%;}
#head h2 {color: #222;}
#nav {}
#nav li {}
#content {}
#content img {}
#footer {}
Great point Jason. That’s the way I also write CSS.
I see a lot of people here that sorts the styles alphabetically. It’s clear to me that the only way they can find a rule in the stylesheet is to scroll till they get to the letter their rule starts with.
If they knew how to use the browser inspector to identify a rule, they wouldn’t bother a second about the sorting. Sorting alphabetically is a lot of work for nothing, anyway.
It makes more sense to sort the rules according to the section of the site they apply to, exactly as you show above.
I agree with the above sentiments. I write/organize my CSS in the order of how the rules would appear on the actual site. It makes more visual sense for me to organize how it’ll be seen not how I’ll search for rules in a text editor – especially considering if I’m looking for something chances are I either know where it is or I have my hand poised over CTRL+F. If you know how to quickly search a document, ordering at all really becomes moot.
That being said, I also add comments to the sections in large stylesheets so anyone looking later will know what that section is for (even if it’s obvious).
Now if only WordPress theme developers would adopt some kind of coherent method for organizing their stylesheets (can I get a HELLS YEAH?!)
Is there any good software that enables sorting of properties?
So if people have different preferences they could easily reformat/resort them.
Each person could work in whatever way they personally find most suitable to them, and then reformat it according to the final needs of the project.
People inheriting code from existing projects could similarly reorder properties to their preference before continuing to edit the code.
I’ve seen CSS optimisers available online but they didn’t alter the property order.
I’m interested to hear others’ thoughts or experience of this.
This might be what you are after: https://github.com/miripiruni/CSScomb/
I used to use TopStyle years ago and it had a feature to clean up and reorder CSS based on whatever settings you set. I tried the CSScomb plugin for Sublime Text 2 and Notepad++ and neither of them worked, so I tried the CSSTidy plugin, which cleaned up the CSS, but didn’t reorder anything, so bummer…
I fallow Harry Roberts @csswizardry and Mark Otto @mdo suggestions.
Hi Chris!
How about this for a poll idea:
What is the hardest language you had to learn?
a. PHP b. HTML (ha!) c. Javascript d. Ruby, etc.
@steph …. hmmmm difficult ques . Ruby is the answer, as i don’t know it :(
I have dabbled in web design for many years (back when tables were a fad) and am only now working my way to becoming a professional. Over the years I have found that like some have said, alphabetical works for me. I find that when I am with a client who wants to know why this is positioned here, or how the size changed, have the CSS alphabetical allows me to scan quickly while giving my presentation. I have tried other “modes” such as by type, or by logic of order, but even when I have randomly added something on the fly, I go back and put it where it goes alphabetically and is the quickest for me. I think these days it really comes down to the comfort zone of the designer. Not to mention how easy it is to show some of my clients (who want to learn it) how to change the properties because they know that background will be in the front area, and z-index will be in the back area and easily reachable.
Awesome. I have a strict structure that I follow, and it’s group by type. With one exception: background goes last.
I’ve been questioned about my methods, and other developers have even tried to make me do alphabetical.. ha! It’s great to see that others think similarly.
Glad to know I am not the only one so particular about the order they write CSS. I am grouped person. I work on a large web application and it makes it easier to scan through CSS when you know what is coming. I never like the alpha or random methods (although when in a rush I may not follow the grouped order but I go back and fix it later).
Well using MSVS it’s pretty much done for you. I just use the “document outline” view and it takes care of grouping the CSS for you neatly.
I have used grouping as many people do it now. But i discarded this approach due to inability for a fast search in a simple notepad.
When you write a new css from scratch you want to make it as soon as possible, so I reccomend everyone to write the properties in alphabetical order in such situations. It will save much time to you in the future.
This is the strangest explanation so far. Have you heard of browser inspector to find a rule that you want to edit?
Why do you need to search inside notepad by manually scrolling when you can use Ctrl +F?
And if you work on an existing css that has 1000+ lines of code, do you first spend a day or two re-ordering the existing rules alphabetically?
You know, there is a grouping that makes 1000 times more sense. That is grouping by sections that styles apply to:
Eg:
css reset styles…
header styles…
sidebar styles…
content styles…
footer styles…