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?

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?

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.

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.

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.

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.

I like going with “type” as in CSS many properties have a strong relationship, for example position and z-index.
If a rule evolves and the element is styled as static, then there is a good chance the z-index declaration will not be cleaned up unless those 2 declarations are close to each other.

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.

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.

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.

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 assign margin: 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?!)

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 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.

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).

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.