Grow your CSS skills. Land your dream job.

New Poll: How do you order your CSS properties?

Published by Chris Coyier

Tossed up a new poll (in the sidebar of the site, RSS folks) about how you order your CSS properties. For example:

Random

.module {
   border: 1px solid #ccc;
   width: 25%;
   padding: 20px;
   position: relative;
   min-height: 100px;
   z-index: 1;
   border-radius: 20px;
}

Alphabetical

.module {
   border-radius: 20px;
   border: 1px solid #ccc;
   min-height: 100px;
   padding: 20px;
   position: relative;
   width: 25%;
   z-index: 1;
}

Grouped by Type

.module {
   width: 25%;
   min-height: 100px;
   padding: 20px;

   border: 1px solid #ccc;
   border-radius: 20px;

   position: relative;
   z-index: 1;
}

Spaces just for emphasis.

By Length

.module {
   border: 1px solid #ccc;
   border-radius: 20px;
   position: relative;
   min-height: 100px;
   padding: 20px;
   z-index: 1;
   width: 25%;
}

More dramatic examples.

Others

If you have other ways of ordering, share in the comments! Too late to add them to the poll, but not to late to share.

Comments

  1. Since I mostly code with SCSS, I tend to do block styles first and then positioning after if needed, just reads easier, though in the production type enviroment I work in, I’m mostly doing random just to get the job done quicker, because I’m the only one who will read the SCSS version in our office. When I do have to use CSS outright for edits or tweaks to current sites, I most definitely do random, but we do single line css, not multi-line, for us it’s visually easier to find what we’re looking for in single line css. When I was first learning CSS I was a stickler for grouping and making my CSS look pretty, but once it was in someone elses hands here, it was ruined. lol.

  2. Random, but I have a feeling that this will change once I see the results of this poll.

  3. Rémi Grumeau
    Permalink to comment#

    I always start with display / float / position / top / left.
    Then width/height/padding/margin
    Then text / color / text align /font size / …
    Then border / background
    And last, prefixed statements like shadow, radius, animation, transform …

    • I do the same, except that font styling comes after border/background.

    • Pretty much exactly this. Positioning > Size/margin/padding > Appearance stuff > Background > Border > Prefixed stuff.

    • Mee too, as Rémi and Bill.

    • Yup, I do exactly this.

      Usually stick a blank line between each of the sets to make it easier to read.

    • Guy
      Permalink to comment#

      +1 for the 'outside -> in' approach.

      Often have to fight against a co-worker who thinks that alphabetical is more logical.

      I also tend to put CSS3 at the bottom…

    • Kenton
      Permalink to comment#

      Mike Kretz, I do the exact same thing.

    • Pretty much the same for me. And also css3 stuff at the bottom because of the many browser prefixes.

    • pretty much this. since we have been prefixing things I have moved towards the blank spaces between groups too.

    • I do the same. Makes it easy to find stuff quickly later on.

    • Same here. Though I’m not fanatical about the ordering, but I do have two distinct groups: First it’s all the block-like properties, then the second group comprises of decorations and text styles.

    • Permalink to comment#

      @Remi Same here. I find it quickly find declarations when I come back to my code in the future if grouped by type. I usually alphabetize within those groups as well.

    • yep, same here. I usually do margin/padding before width / height, though that may not be the most accurate considering the default box model.

    • Daniel Waltz
      Permalink to comment#

      Wow, me too! Just a little bit different.

      Positioning > Background > margin/padding/size > Border > Appearance stuff > CSS3

    • Alphabetical all the way! It’s a gazillion times easier to find properties when you need to modify stuff!

    • Sam Hodge
      Permalink to comment#

      I do the exact same thing, though my font/text styles come after the border/background. This keeps in line with the ‘outside -> in’ rule mentioned by Guy.

      The only exception is sometimes I’ll put line-height directly after height because I usually want those values to be the same.

    • Codezyne
      Permalink to comment#

      This.

    • Yep, starting with positioning moving on to dimensions and then finally onto content and special styling has always been the way to do it for me.
      ..sometimes I’ll do dimensions first and then positioning, but rarely.
      Really its about what is intuitive when reading the css declaration and imagining the element.

    • Laura
      Permalink to comment#

      Me too! And then, for whatever reason, z-index is always last.

    • Be amazed.
      Me too!

    • Paleogirl2003
      Permalink to comment#

      Yup, pretty much this order

    • Permalink to comment#

      Another ‘same here’ from me. Just started ordering my css recently, though… it was random up until a few months ago.

    • Pretty much the way that Mike Kretz does it, too, except I don’t separate out the prefixed statements.

      Looks like (with small variations) a lot of people have independently chosen this approximate sorting.

    • almost the same: positioning, size, background, font, padding-margin-border, ‘prefixes’ and animations, accessories (i.e cursor), display
      never went random
      :)

    • Michael E J
      Permalink to comment#

      I’m similar. Position, structure, visual, then typography if needed. If I’ve got CSS3 pieces, they always end up last.

      As for working in other people’s code, I’m always hunting things in Firebug, so the order in which they declare things isn’t a huge deal.

    • Mason
      Permalink to comment#

      This approach has always seemed the most natural to me too.

    • Same as Mike Kretz, on a single line. It’s always seemed intuitive but seeing all the responses confirms how evidently intuitive it is.

  4. Grouped by type — starting with font, then measurements for witdth/height/margin/padding, then the rest, ending with long CSS3 declarations

    • Permalink to comment#

      Same here — font, sizing, miscellaneous, and then the fun stuff like transitions or transforms. When I’m writing in SCSS, extends and includes go first though.

      I’ve always wondered if there was a best practices approach. Apparently it’s just personal preference.

  5. By type, but alphabetical by type.

  6. Permalink to comment#

    A combination of length and type. I love performant code, but I’m also OCD, so there ya go…

  7. Alphabetically – because it is easier to find something.

    • This. Get with it people.

    • 100% agree!

    • This is the best way in my opinion. It’s the only way to quickly and easily find rules no matter who wrote it.

      Unless if there becomes an industry canonized method for grouping by Type, that *all* developers can consistently follow, grouping by type just becomes a latency circus, as devs who do this method rarely do it the same themselves, much less between each other.

    • I just don’t think that organizing properties alphabetically adds that much value though…there shouldn’t be enough properties that having to find something alphabetically will make much impact…but I could easily be wrong…I’ve never ordered mine alphabetically, so you might be onto something.

    • @Jordan – The difference is huge. If you work on teams, often jumping into existing projects that were authored by someone else, you have to guess at what type of organization they’re using. It may take a split second to over a second of scanning and grokking.

      With alphabetical, you know exactly how every style property is organized and it saves time and mental energy from having to scan for what you’re looking for. It frees you up to concentrate on “what do I want to do” not “where is what I want to do” or even “where do I put what I’m doing”.

    • Alphabetical to improve gzip compression. Same thing with selectors. I also group selectors so a particular css property is never repeated.

    • Alphabetically that is… but by type when necessary. For example, I group the top, left, right and/or bottom properties right after the position property – that makes a bit more sense.

      Margin and padding always go as a block.

      Otherwise, everything else is by position. I don’t really do prefixes, since it’s easily fixed by prefixfree.js :)

    • Phil
      Permalink to comment#

      Same with me

    • Permalink to comment#

      Alphabetical. Sometimes I fret that I’m doing it wrong, but I can’t imagine doing it any other way.

  8. Andy
    Permalink to comment#

    Random for me.

  9. By type, of course! Humans don’t think or work alphabetically.

  10. Jason
    Permalink to comment#

    By type, and out of habit. I never set out to do so, just happened naturally over the years. I would assume if I was anal enough to do it alphabetically it would increase the amount of time it takes to write styles by a power of 4.

  11. Random, but random usually comes out partially ordered by type.

    I have never had a problem reading properties because there were too many.

    • Will
      Permalink to comment#

      I usually just go with the flow.. The more I try to focus on the grouping the less creative I become. Thus I just do it random and it eventually does end of being semi grouped. I do however tend to put my css3 at the end

  12. Random, but I always start with width and height. Other things follow randomly :)

  13. Randomly :)

  14. By type :
    * content (if generated content, so you can see it directly if you can’t see the :before/:after)
    * display
    * position
    * box properties (width/height, padding/margin and border)
    * position properties (top, right, bottom, left)
    * backgrounds properties
    * font properties
    * misc (opacity, transition, etc…)

    • Chris Lebron
      Permalink to comment#

      +1, all the way down. Though I must admit, z-index and zoom (IE hasLayout “hack”) often come last for me. Guess I can’t completely shake the urge to alphabetize…

    • Chris Lebron
      Permalink to comment#

      Ooh, actually, I should amend that. I usually put individual position properties right after float & positioning, then followed by box properties (outside–in, of course).

  15. Permalink to comment#

    We settled on alphabetical here, because the dev team couldn’t maintain a consistent way of grouping by type – and the order in which to do that etc. It is a good way of doing things but with several of us working on a project it is easier to scan and find a property if it’s alphabetical.

  16. I start with structure like:

    #something-short-but-semantic {
    display:block;
    position:absolute
    width: 98%;
    top:50px;
    

    then maybe some styling:

    border:solid 1px #EEE;
    -webkit-box-shadow:  0px 0px 15px 0px rgba(0, 0, 0, 0.2);
     box-shadow:  0px 0px 15px 0px rgba(0, 0, 0, 0.2);
    

    Then the font stuff:

    color: red;
    font-size: 1.8em
    line-height: 2em
    }
    

    except.. written in SCSS.. so, a little more complicated.

    • In a team, I use whatever convention the rest of the team uses.

      For personal projects, I group by what’s relevant up top.
      Inline elements are usually about typography.

      p {
      font-family: 'Helvetica Neue', Arial, Helvetica;
        /* because Arial looks better on Win */
      font-size: 1em;
      line-height: 1.2em;
        
      color: #333;
      background: #f4f4f4;
      border: none;
      
      padding: .25em;
      }
      

      Block elements are usually about display, size, & position.

      section {
      width: 80%;
      margin: 0 auto;
      display: block;
      position: relative;
      float: left;
      
      background:badca7;
      border: 1px solid #bada55;
      }
      

      I’m probably crazy, but this is what works for me.

  17. Permalink to comment#

    I write my CSS randomly at first then when it goes into more property, I grouped them for easier access of relative properties when it came to the point that a single element will consist of more than 5 property.

  18. Been an A-Z man for about 4 years. It certainly took some time to get in the groove, but after doing it a while it became second nature. I just feel like for me I always know where things are which speeds me up.

    Everybody’s brain works different I suppose, so what ever works for you is what’s best. However, I’d love to see a study or to about the implacations of something like this.

  19. Wouter J
    Permalink to comment#

    I have choosen ‘by type’, allthough the example isn’t what I think is ‘by type’. I sort it like this:

    .module {
        display: block;
        width: 25%;
        height: 200px;
        padding: 10px;
        margin: 5px;
        background: #000;
        border: 1px dotted #333;
    
        font: 16pt Georgia, serif;
        font-weight: bold;
        text-decoration: none;
    
        position: relative;
        top: 25px;
        right: 5px;
        bottom: 2px;
        left: 25px;
    
        -webkit-box-shadow: 1px 2px 5px #000;
        -moz-box-shadow: 1px 2px 5px #000;
        box-shadow: 1px 2px 5px #000;
    }

    Some points of interest:
    - position properties are sorted as margin values are sorted (top, right, bottom, left)
    - all prefixed properties are at te bottom, each at there own group
    - first the inner styles (background, padding) and then the outer (margin, border) and then the outer outer (like outline).

    PS: The strange indenting is an error in this commenting system.

  20. I do:

    Floats, Clears, Position, Top/Left/Bottom/Right, Width, Height

    Text, Line-heights, Font Styling

    Display, Cursor, etc.

    Border

    Background

    CSS3 Properties (Box Shadow, Text Shadow, Etc)

  21. Pierre
    Permalink to comment#

    I used alphabetical order for years because I thought it was easier to scan and find a particular property, but I tend to group them by type, especially since I use Sass (display/box-model/positioning, colors, fonts, other).
    The problem with type grouping is that there’s no rules, so you need to write your own, particularly when working with a team.

  22. Permalink to comment#

    Random for me, but sometimes I’ll block related styles together, kind of like Wouter J does.

  23. selector {
        POSITIONING LINE [position,top,left,clear, ETC]
        BOX MODEL LINE [display,margin,border,padding,width, ETC]
        TYPOGRAPHY LINE [font,text-indent,font-style, ETC]
        PREFIXED PROPERTIES [-moz-,-webkit-, ETC]
    }
  24. I usually order them by order of priority in my own eyes. For example, I would prioritise technical structure over look and feel. Display, width, height, position, margin and padding would be more important than color, font, background etc.

    It just works for me but more often than not any sense of order quickly goes out the window but I try to keep everything organised as much as possible.

    .module {
    display: block;
    width: 100%;
    height: 300px;
    position: fixed;
    top: 0;
    left: 10px;
    margin: 10px 5px;
    padding: 20px 30px;
    color:#fff;
    background: #333 url(‘blah.gif’) repeat-x top;
    }

    Although in the short term it may take longer as it’s very tempting to write it as jumbled up as it usually comes out of your head it saves time in the future when you come back to making amends and adjustments.

    Scott

  25. Completely random, but I make sure they’re not padding-left, right, and by 0 0 0 0

  26. Which renders faster?
    This is more important than how it looks.

    • I don’t think the order of properties make any difference in loading speed.

      But we can make a test…

    • I had the render time in mind, not loading speed. A test would be great.

      Btw., I´m used to order it alphabetically.

  27. Michael Swanson
    Permalink to comment#

    I haven’t written straight CSS in a while I use mostly SASS but I always order properties alphabetically because I find it easier to scan and find them.

  28. I use the order learned from Raphael Goetter : http://blog.goetter.fr/post/14503308074/ordonnez-vos-declarations-css, with a tool I created : http://csslisible.com

  29. Essentially random, but with some grouping thrown in.

    New blocks will be made with a view to grouping types as per example but new additions as css file is developed rarely respect the initial ordering. So new additions to a rule sit at the bottom, this gives an ordered top half and an unordered bottom half … so random.

    So how to vote? Were I ever to have the luxury of time to refactor a css project, i’d go ordered. But pragmatic reality is random.

    Reality wins, i voted random.

  30. Colyn
    Permalink to comment#

    What you’re showing as “random” isn’t actually random. It’s probably more akin to the rolling credits at the end of a movie. That is, styles are added by order of appearance.

  31. Permalink to comment#

    Alphabetical.

    Firebug and Chrome Dev tools order it that way. When working on large teams, it’s nice to remove the grey area that order by type creates.

    • Brian
      Permalink to comment#

      I completely agree. Tools like Firebug and built-in developer tools show it “computed” in alphabetical order. A whole lot easier to reference when my debug tools are matching my stylesheet layout. Too much opinion can be inserted into what properties get priority.

    • Raanan Avidor
      Permalink to comment#

      same reason here. especially when I make changes in firebug and then copy it back to my CSS file and then commit it to GIT, it is easier to see the changes (the lines don’t change position).

    • EstherH
      Permalink to comment#

      same here! i tweak with firebug and then copy back to my file. after i’m done, i add browser-specific syntax at the bottom

    • Hector
      Permalink to comment#

      I write my Css in firebug, after that I copy/paste in the .css file, so, my order is Alphabetical, is faster I think because you dont have to reload the page for any change you made.

  32. Alphabetically.

    I’ve heard that any recurring patterns in a file will lead to tighter compression, so having some kind of system in place — line length, alphabetization, etc. — could help with that. We’re talking about like maybe a byte or two, but I figure, hell: why not do it?

  33. The IDE should order CSS-properties in the build process.

  34. fp
    Permalink to comment#

    I have never thought of ordering somehow the css properties. So, my answer is Randomly

  35. Permalink to comment#

    Maybe it’s weird, but I do it in the order of the elements in my HTML starter page. Probably not the best way, but it tends to keep things in pretty decent order from top to bottom.

    Example: Header, content, footer, etc.

    • Anna, thats not what this poll is about. You’re referring to the order of your organization of selector+properties, but this is about the order of the properties themselves within each selector’s styles.

      Ordering selector+property grouping isn’t as simple as “Alphabetical” or “By type” as how you organize your styles will effect the styles that cascade down into following selector+properties styles. Knowing how to organize your stylesheet on this global level takes a lot of consideration for the type of project, its characteristics, and future planning.

  36. Steven Braun
    Permalink to comment#

    I order mine by sexual preference.

  37. Brian Hough
    Permalink to comment#

    I group by type:

    Generated Content
    Display
    Position
    Box Model
    Position Properties (top, left, etc…)
    Background
    Font Styles
    Misc(transitions, opacity, etc…)

  38. I try to do alphabetically, but sometimes with block level elements I tend to bunch height and width close to each other. I also usually place position and it’s values at the bottom.

  39. It has to be random right? It takes far too much thought to start planning how to structure CSS properties!

    Plus when you realise you have missed something, do people really go back and add it in it’s right order? No chance!

    • Random is wasteful, and taking the time to do it right becomes 2nd nature. plus, many text editors make it easy to reorder after you’ve finished writing. In Sublime a simple Ctrl+Cmd+(↑ or ↓) to move a line of code up or down w/o even having to select or cut it.

  40. Definetly by type. Before switching to SASS and LESS, It was a bit more random but I always start the class or id with dimensional attributes, then positional then colors etc.

  41. I don’t know why or how I started doing this but I’ve always been ordering my properties starting with background, color, typography, display, sizing, and positioning. The last thing would be the prefixed property. However, I think I might change my order, starting with positioning and sizing properties as has been suggested by many.

  42. echo
    Permalink to comment#

    I do it the way Firebug displays CSS, in alphabetical order. Just easier to edit esp. when I’m styling in the browser. I do a lot of copy and pasting form Firebug to CSS sheet.

  43. I go with what seems right at that time. However, it’s almost second nature for me to start with positioning and size first (width, height, float, margin, padding), and then to focus more on the design (colors, typography), and then, I get it into the nitty-gritty CSS3 properties.

    Any type of logical ordering will slow you down a bit, but realistically, I’m sure people who place their styles “randomly”, that it has some sense to it.

  44. I have started grouping by type and I follow Jonathan Snook’s example in his SMACSS book of:

    1. Box
    2. Border
    3. Background
    4. Text
    5. Other

    This has become handy now i have joined a larger organisation and everyone has adopted the same method.

    I actually have it scribbled on a post-it note stuck to my monitor.

    http://cl.ly/0q1o1u3L2T2g2v0q0A0F

  45. Mixture of type and random!

  46. Grouped by type. Similar to https://github.com/necolas/idiomatic-css#declaration-order, I order my CSS by type, but with a few differences to how he does it.

    I do structure first (display, position, width/height, floats, clears). I differ from necolas in that next I do structural style (margin, padding), because I feel those affect layout. He does padding, border, margin. I typically try to do margin, padding, border. I know that’s incorrect re: box model, but margin has more affect on layout than padding. Next I do stylistic box properties like border, background color, etc. Then font, font color, and things like gradients, etc, last, since they usually have prefixes and multiple lines, so it makes them stand out more.

  47. Up until recently it was always random, but now that I’ve gained more experience I order alphabetically. It definitely helps when going back to my CSS files at a later date!

  48. I use alphabetical but group prefixed stuff by the non prefixed bit and I group top, left, right and bottom together, in that order (so they’re in “t” position).

  49. I tend to do a combination of by-type and alphabetical. For instance, I’ve found that it is much easier to alphabetize most properties, except for width and height… Those are my two exceptions. When I was a kid, I was always taught width, then height, which stuck. For my ease of writing then, I alphabetize everything, with the width, then the height at the bottom. That kind of a hybrid system works well for me!

  50. Permalink to comment#

    Alphabetical except for height/width those I put on the same line. It’s easier to scan and the rules are simple enough so that a team can work on it and still look like a single person coded everything

  51. I generally group it by type. I find it easier if I need to go back and modify the code. I can see it as the basics, the eyecandy, the prefixed-crap-that’s-not-universal, the placement, etc…

  52. dale
    Permalink to comment#

    alphabetical. there’s only one way to order letters and everyone reading this should know how they go (at least i would hope). grouping is based on user preference and does not translate across the same to every developer.

  53. Hsablonniere
    Permalink to comment#

    I go alphabetically because it’s the only universal order. If the community throws some “spec” and propose a common by-type order and if there’s serious adoption and automatic sort in IDEs I would definitely go for that ;-)

    What do you think?

  54. Permalink to comment#

    I voted that I group my properties together by type, but even then the groups are a bit random. For example, dimensions, positions, borders, font styles — Even I never really know what gets grouped first, then next, etc. ;-) I mean, It’s not entirely without thought; I arrange things in a way that makes sense to me, even if it isn’t industry best practice. But then again, I really don’t know if there is a “right way.”

  55. I’m really impressed that Alphabetically choice is in 3rd place. I just can’t code other way. It’s quite easy to find properties and dramatically reduces double declarations.

  56. Adinan Cenci
    Permalink to comment#

    By logic

    display
    position
    z-index
    top, bottom, left, right
    width, height
    padding
    border
    margim,
    text, font
    text-shadow
    background
    shadow

  57. It’s alphabetical for me. In principle, I like the idea of ordering by type and would probably do this if I were only developer involved. However, I often write stylesheets to be used by others, and there’s no obvious and consistent approach to ordering by type. So any developer who updates one of my stylesheets would be forced to either learn my type-ordering approach, or do something different and make the stylesheet less consistent and thus harder to use. By contrast, everyone knows the alphabet.

    Also, a small benefit to alphabetizing is that it makes it nearly impossible to write duplicate declarations.

    Of course, the downside to alphabetizing is pretty obvious: declarations are presented in what adds up to a functional mishmash.

    I will say this: If I ordered by type, I would probably alphabetize within the types.

  58. Eloise
    Permalink to comment#

    It ends up randomly although it doesn’t necessarily start that way.

    I usually start off putting them up by group as planned. Then as extra little tweaks come along they get added to the bottom. I’m not sure how long my longest single css declaration is, but less than 20 lines I’m sure. When I’ve got a CSS file that might 300+ lines, scanning through the right 20 lines is hardly a challenge.

  59. Ricardo
    Permalink to comment#

    Alphabetical!

  60. Covarr
    Permalink to comment#

    Mine seems random, but it’s really not; it’s chronological; left-to-right in the order I write it (I also typically put all properties for a selector on one line). Occasionally something will be grouped instead, such as if I decide to change a border and add a radius at the same time, because my cursor’s already there, but otherwise it’s pretty much all in the order I write it.

    Amazingly, I have no difficulty finding things this way. Usually I don’t have enough properties on a single thing to warrant putting a ton of effort into organizing it.

    What’s more of an issue for me is how I arrange my selectors: I try to organize them in roughly the same order their respective elements appear on the page. It’s not always perfect, but it really helps me to visualize it while I work.

  61. Simple.

    First I decide what size it is, then I put it where I want it to go, then I make it look nice.

    The making it look nice code goes in no particular order.

  62. I order them alphabetically and to keep stuff like width and height together I’m using Stylus transparent mixins.

  63. Permalink to comment#

    Grouped by type, of course. It is the *correct* way :)

  64. Alphabetical!

  65. I mainly do alphabetical as well.

  66. Random. I find when I try to apply rules at this level I start spending too much time on the code in a way that doesn’t directly benefit. I think you can keep CSS too organized.

    I don’t generally have a ton of properties, so I don’t think it’s ever slowed me down.

  67. I am random, but I also kind of group them. Just for convenience. Like I will put background-color and color next to each other, and the border-radius all in a line as well.

    I’m not CRAZY meticulous about that stuff just a few subtle habits I have.

  68. I definitely order alphabetically. I’ve found that using this system, it’s much quicker making changes in the future. It was a pain to train myself, but very worth it when you get the system down.

  69. Alphabetically. A more interesting question is how do you order your CSS selectors?

  70. Permalink to comment#

    I do alphabetical. Because anyone can pick that up at any skill level, and way too often other methods have lead to multiple declarations overriding each other.

  71. Usually it’s random for me. I guess it would be more random by type. I usually start with background color, width/heights, typography, margin, padding, etc. I never even thought about ordering them alphabetically. Hmmm…

  72. Matt Combs
    Permalink to comment#

    I always list mine alphabetical, but that’s because long ago I decided to follow the Google Developer Standards for coding.

    http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml?showone=Declaration_order#Declaration_order

  73. Junior Eberhardt
    Permalink to comment#

    eu uso o modo alfabético, assim quando estou procurando uma propriedade fica mais fácil…

  74. I prefere to use alphabetical order:

    selector {
     ׅ ׅ color: red;
     ׅ ׅ display: block;
     ׅ ׅ height: 42px;
    }

    with some exceptions:

    selector {
     ׅ ׅ color: red;
     ׅ ׅ display: -moz-inline-box; display: inline-block; *display: inline; *zoom: 1;
     ׅ ׅ height: 42px;
    }

    where I use the main property (like display here) as reference.

    I also group vendor alternatives and use the regular property to position the group in the list:

    selector {
     ׅ ׅ -webkit-border-radius: 3px;
     ׅ ׅ ׅ ׅ ׅ -moz-border-radius: 3px;
     ׅ ׅ ׅ ׅ ׅ ׅ ׅ ׅ ׅ ׅ border-radius: 3px;
     ׅ ׅ color: red;
     ׅ ׅ display: -moz-inline-box; display: inline-block; *display: inline; *zoom: 1;
     ׅ ׅ height: 42px;
    }

    I tried to use a grouping approach in the past but sometimes it could be ambiguous. As some properties could be used to achieve different things.
    Another problem is that everyone could have its own grouping approach/order but there is a single alphabetical order.
    Also, the grouping approach become useless as you get comfortable with css. It comes a point where it’s harder to find the property in the css than to find the property used regarding the result.

    So, once you know css, the real problem is not to find what is in it but where it is. The alphabetical order is the best solution for me.

  75. Random right now, but when I see the result, I’ll change accordingly.
    Thanks for the poll!

  76. I totes am like, “HEY YOU PROPERTIES! LISTEN UP! YOU’RE GUNNA TAKE SOME ORDERS NOW!”. Seems to work well.

  77. …with a side of bacon!

    Semi-random with related properties grouped together. When I get closer to the final form, I’ll arrange the margins in T R ou B L e order…

    If the definition gets too big, it’s often an indication that I need to refactor into separate mix-in classes. Then I ask myself questions like: “is .myclass always red? Or should I use ?”

  78. oops, it didn’t HTML-encode my example… should have read: “…should I use <div class=”myclass error”>

  79. Mark
    Permalink to comment#

    Alphabetical with CSS 3 at the bottom.

  80. Structure/font-text/colors


    .class{
    width:value;
    height:value;
    padding:value;
    margin:value;
    border:value;
    ....

    font-family:value;
    font-size:value;
    text-align:value;
    text-decoration:value;
    ....

    background-color:value;
    border-color:value;
    color:value;
    ....

    }

  81. I group CSS properties in the order in which it occurs to me to add them to the stylsheet, so I would be filed under random.
    Though I tend to have a pattern emerge in how they are grouped. Things like margin and padding and width/height tend to naturally end up together. Sometimes though, I do group them on purpose when i go back to edit.

  82. I prefer to order my declarations by type, but also by the relationship between the declarations (for example, I declare padding next to margin because they are similar).

    And I like to declare basic properties (such as padding, width and height) first, and then more “complex” properties (such as box-shadow).

    However, I guess I am going to try organizing declarations alphabetically. After seeing it here, it seems to be the best way, because it makes all the sense!

  83. sort by type online: http://csscomb.ru

  84. Alphabetical!!

  85. cnwtx
    Permalink to comment#

    Newest written at the bottom, which can either end up random or by type, depending on what I’m working on at the time.

  86. bigbossSNK
    Permalink to comment#

    Grouping and (hierarchical) ordering can also make finding bugs easier.

    To highlight an example,
    Absolutely positioned elements and floated elements override display declarations, other than display: none.
    If you order your declarations as

    position
    float
    display

    finding why your declared inline-block just turned into a block becomes much easier.
    Just look for any overriding properties ahead of the current declaration.

  87. PattyJ
    Permalink to comment#

    I just realized that what I do isn’t random at all – it’s “newest written at the bottom”. And I’ve never had any problem finding a declaration within a style block!

  88. I tend to group by type, working outward in… margin..border.. padding.. width/height.. background..etc … I’ve been using less for a while, and more so on a current project with bootstrap.

  89. I usually order my CSS alphabetically at the start, but if I have to tweak properties (and I will), it ends up having the newest style rules at the bottom for convenience. Firebug is by far my most used tool when it’s time to polish and readjust.

  90. Jamie
    Permalink to comment#

    I am random. Is that bad?

  91. Robin
    Permalink to comment#

    Not really strict about it but usually go outside -> in

    Most of the time I don’t really mind because I’ll just comb it afterwards.

  92. I have enough things to worry about then worrying if border-top should have gone above border-radius…because r comes before t in the aphabet…I have never had a problem scanning the CSS properties for a particular selector…maybe this is just me…looking at the stats I appear to be in the minority…though a large minority…

  93. I’m another that goes from the outside -> in. It makes logical sense, because the positioning of the elements is what I do first.

  94. I order it by alphabetical.

  95. I do alphabetically, with the exception of things like positioning. (I use 2 spaces rather than a 4-wide hard-tab for these kinds of things)

    .selector ...{
        ...
        border: ...;
        color: ...;
        position: absolute;
          left: 20px;
          top: 5px;
        ...
    }
  96. Presentation first, followed by layout. Easier when working on a mobile-first, responsive website.

  97. Alphabetically :)

  98. Nice point!
    Currently i make it alphabetically.

  99. Nice tutorial on How we can manage our css code.
    Thanks !

  100. Alberto
    Permalink to comment#

    Before reading this, I was usual to use a random order.

    But I really like the Grouped by Type order. It feel much nicer to look at.

    How can you order them by Alphabetical?? It’s a insane way… I don’t know exactly what I will write in the code until I don’t write it. To order it Alphabetically, you have to think exactly what to write before writing it.

    • Why ? Do you know that you can put the caret on the line you want and insert new line between two existent ones ?
      I’m just kidding but when I read your comment it looks like we can’t put code in superior lines (sorry, english is not my native language, I try to be as understandable as possible ;-)), just like if we code with typewriter.

  101. Glad to see quite a few randoms – I suppose it depends on if you work alone or in a team.

    Am not too good on style sheet organisation either. I worry about that more – generally use the order that things appear in on the front end (ish)

    I tend to worry more about what the front end looks like!

  102. I’m somewhere in between random and by type, but I’d venture to say I lean more toward random.

  103. I think this “Grouped by Type’ work great for me. It help me to debug faster.

  104. I hadn’t even thought about it before really, but I definitely tend to organize by type. Not intentionally, and not even 100% of the time.

    If not ordered by type I often leave it alone, though sometimes it does irretate me enough to copy and paste things into a more desired place.

    One big one for me is width and height ALWAYS have to be next to each other and in that exact order as well, as images are most frequently referenced in size by width before height.

  105. Unrelated: I got served a diaper add in the sidebar!?

  106. Completely random

  107. I group things in logical sections. Especially when I am working on responsive designs.

  108. Very Very random, but reading all this I will look forward to seeing the poll results.

  109. random !!

  110. Permalink to comment#

    Random.

  111. I have my own logic:

    Display
    Position
    Float
    Background
    Width
    Height
    Margin
    Padding
    Font-family
    Font-size
    Color
    Text-decoration
    Text-shadow, etc.
    Border
    Border-radius
    Box-shadow
    Z-index

  112. i order properties only in big rules, and i order them by type

  113. I have a secret word(can’t tell you what it is, it’s a secret) That I then spell out using the first word of each property for each class.

    This is fun, but means even i would have to assign a property(and make it equal to nothing) even if it’s not needed.

    You may call it OCD, I all it bad ass styling.

  114. .selector
    {
    content: ;
    color: ;
    font;
    background: ;
    border: ;
    padding: ;
    margin: ;
    position: ;
    width: ;
    left: ;
    float: ;
    display: ;
    text-decoration: ;
    box-shadow: ;
    z-index: ;
    }

  115. I start off nice an consistent with grouping my styles into section but half way through the project I tend to just throw things in randomly ^^

  116. Alphabetical, that’s the most simple solution when working in big teams I think.

  117. william malo
    Permalink to comment#

    I put sizing and positionning first, then box styles, then text styles.

    Ex:
    width:30%;
    height:100px;
    margin:30px;

    background:#efa;
    box-shadow:0 0 10px #000;

    font-size:20px;
    text-shadow:0 0 3px #fff;
    color: #fff;

  118. Kelsee
    Permalink to comment#

    Grouped by type for sure!

  119. Random for me.

    • random… it just works better for me, i can code much quicker if i dont have to think of an order to put them in… plus, if i need to find something to quickly change it just hit cmd f and find it that way…

  120. By type, first positioning, then fonts and then the rest.

  121. in a rush > Random
    most of the time > Grouped by Type
    when have more time > Grouped by Type + By Length

  122. Permalink to comment#

    Alphabetically for me. It’s universally understood whereas some of these type-based schemes might work for a single individual, many of them, whilst similar, have slight differences; maybe sizing comes before positioning, maybe after, maybe on the same line.

    Alphabetically makes it far easier for me to find what I want to edit and prevents me inadvertently adding, say, two padding definitions on the same line which I have managed to do in the past with a type-based ordering scheme.

    Of course reading the number of comments so far, it’s clear this is quite an emotive subject.

  123. Alphabetical, because it is the only universal standard that everybody intuitively understands. Grouping by type still leaves too many options. Furthermore, alphabetical is THE standard in use by virtually every web inspector tool, built-in in browsers or 3rd party.

  124. Hi Chris,
    I regularly work with Firebug! So I order alphabetically. How do you order your CSS?

  125. Grouped by type for sure. Just seems natural to me when I am writing out the width to add the height (if need be of course). Margin by padding, etc. To me it makes it more obvious when I have a width, margin or padding issue to be able to find it.

  126. I group mine by the type of property in a logical order. E.g.:

    #selector
    {
    /* Position and dimensions, layout related */
    display: block;
    position: relative;
    width: 100px;
    height: 100px;
    margin: 10px;
    
    /* Type */
    font-family: Arial, sans-serif;
    color: #000;
    line-height: 1.667em;
    
    /* Visuals (don't affect type or layout) */
    background-color: #FFF;
    border: 1px solid #CCC;
    box-shadow: 0 0 2px 0 rgba( 0, 0, 0, 0.125 );
    
    /* Others (rarely used) */
    cursor: pointer;
    }
  127. Alex
    Permalink to comment#

    I don’t order them usually, but when do – I order them by type without any empty lines. Actually I think it’s not important much.

  128. Jon
    Permalink to comment#

    Position
    Float
    Dimensions
    Margin
    Padding
    Background
    Border
    .
    Everything else ordered alphabetically.
    .
    Color

    I haven’t found a place for CSS3 animations/selectors that I’m really happy with though.

    Also it *really* annoys me when folks don’t add a space after the colon. Fugly!

  129. After a few mishaps where the same property was listed twice (why isn’t my padding change working?!?), I’ve generally been ordering them alphabetically.

    I do see the value in ordering by type. I would like to know up front if something is display:block, floated or positioned. It also seems like a good idea to keep height and width, and top/bottom and left/right together. CSS3 selectors grouped at the bottom makes sense too. I’m open to change.

    Random…nope. Not even if I’m in a hurry.

  130. James
    Permalink to comment#

    Alphabetically, grouping by type is a great idea though.

  131. Robert Huttinger
    Permalink to comment#

    Once it is organized in the order you want, and if you are anal like me, use this script to make it readable!

    #! /usr/bin/perl
    use strict;
    use warnings;
    while (){
    s/([-a-z ]+:([^link|visited|hover|active]))\s*(.*)/sprintf(“%-32s”,$1) . “$3″/ie;
    print;
    }

  132. Bingo! Check out CSScomb here, or here. Completely customizable by the looks of it and available for a whole bunch of text editors!

  133. Actually… I’ve just found that Sublime Text 2 has sorting functionality built in… Select the lines you want to sort (not just CSS mind you), Ctrl/Cmd+Shift+P, then type ‘sort’, hit enter and bam… your properties are now ordered logically!

  134. Ryan
    Permalink to comment#

    Andy Ford has a great post regarding this issue. I’ve been using his ordering (for the most part) for about 3 years and it really is helpful when you revisit a project and have to find things quickly. Alphabetical sounds great but for me it ends up being more time consuming… “What I don’t like about alphabetization is that certain properties – in my mind – have inherent logical connections and should not be separated from each other.” -Andy Ford

  135. Andrés Roberto
    Permalink to comment#

    I order them alphabetically. Since the most of my classes separates the layout, color and font-related properties, I don’t order them on that basis.

  136. Alphabetically, since day one. Because eventually, no other way will make sense (i.e. grouping by what?).

  137. Chris, you made me think about what I do, I knew I didn’t do any of the options in your poll, but I wasn’t sure what it is that I actually do. So you made me think about that, and why. Thank you.

    Personally, I can’t see how any systematic, alphabetic, line-length or group-by-type ordering can possibly be properly maintainable.

    Yes, we can maintain the alphabetic order or whatever, but that’s not maintenance, that’s just having some arbitrary organisation that doesn’t really assist maintenance as much as it can. We should be maintaining styles for a website, not just a bucket of CSS properties.

    We should be able to maintain our CSS, without having to re-order its properties once we have carried out a change. Why? Well, in a multi-user version control system, we need to see the changes, and only the changes, there should be no danger of a change appearing as though a line was deleted and another was added, a change should look like a change.

    When creating a CSS ruleset, the properties within it should be in the order of perceived importance, i.e. which properties contribute most to the desired style.

    As I tend to switch between editing CSS and viewing its test page in 7 browsers quite a lot (oh, you have got to create an extensive test page, that is crucial). Life is too short to go reordering the properties once I’m done styling a component.

    It tends to turn out something like:

    /* inline forms are usually tiny, e.g. a single field and a submit button */
    form.inline div.field label 
    {
      padding-right:0; /* Remove spacing reserved for required asterisks */
      float:none; /* Prevent labels appearing above the fields in Opera */
      width:auto; /* Reduce width of labels in IE7 */
    }

    So it’s in accidental order of the priority of my goals at the time of writing.

    Any fixes for certain browsers are appended to the bottom as they are addressed, and the goal of (or reason for) the property is always commented, very important!

    We don’t have to comment every line individually though, a comment on its own line above multiple properties, followed by a blank line is adequate for comments like:

    /* The first item in the menu */
    ul.menu > li:first-child
    {
      /* Round the top-right corner */
      -moz-border-radius: 0 20px 0 0;
      border-radius: 0 20px 0 0;
    
      /* Invert the colours */
      background:#066;
      color:#fff;
    
      font-size:1.3em; /* Larger text for links to a main section page */
    }
    

    So this way it’s clear why each property exists. (Have you ever maintained a CSS and wondered whether a particular property was absolutely necessary? I have.)

    Suppose the order was random/alphabetical/type/line-length, I’m quite sure in the short term, that can be very pretty and seem to make sense, but come back to your CSS in a few weeks/months/years, once your short-term memory has forgotten what you were doing, you will return to a beautiful mess, and you will inevitably find yourself having to start-up your favourite web-inspector to reacquaint your short-term memory with what the hell you did.

    Incidentally, I voted ‘random’ because once I have the properties for a goal/reason, there aren’t usually enough of them to care about how they are ordered (the goal/reason is probably too general if it has so many rules), however, it still tends to be that the properties are in the order of greatest contribution to the desired goal.

  138. Sergey Syrkin
    Permalink to comment#

    We use: github.com/miripiruni/CSScomb.git :)

  139. More interesting yet: how do your sort your selectors? :)

  140. I sort from most influential to least influential to the structure of the element, working my way from the outside in.

    These properties are first because they directly influence the visibility/structure and/or position of the element.
    display
    float
    position
    top
    left
    z-index
    overflow

    These properties are second because they directly influence the size of the element, again working from the outside in.
    margin
    border
    padding
    width
    height

    These properties are next because they influence the size and look of the content within the element in many cases increasing the size of the element indirectly, making them more influential than the last group.
    font-family
    font-size
    line-height
    font-style
    font-weight
    text-align
    text-decoration
    text-transform
    color

    The last group consists of properties that are not directly linked to other property groups and do not influence the size of the element at all.
    background
    cursor
    outline
    box-shadow
    transition

    I know most people don’t do this but I write my properties in a single line like this:

    .selector { display: block; margin: 0px; border:0px; padding: 0px; font-size: 1.2em; line-height: 1.6em; color: #000; background: #fff; cursor: pointer; }

    I know many don’t like this, but I hate to tab in (even though my text editor does it for me), I hate how the closing bracket looks when you do a per line without tabbing in and this method takes less characters than tabbing does.

    I know its a bit weird, but my structure works for my over logical, perfectionist mind.

  141. I have my own way with my own rules which could be weird for others, but I explained it here a few weeks ago: http://visuellegedanken.de/2012-05-29/my-css-coding-style-part-i-css-properties-order/

  142. Grouped in semi-specific order: position / margin / padding / background / border / text / display / float / cursor / z-index

  143. Bobby
    Permalink to comment#

    I always go for grouped one.

  144. Permalink to comment#

    With SASS/SCSS I usually include all my mixins first, and then continue to sort by type and finally indent the rules to align.

    .foo {
        @include font(2.1rem, 3rem, $font-default);
    
    
        background:     #f0f;
    
        color:          $c-body-copy;
    
        height:         200px;
        width:          200px;
    }

    The output isn’t necessarily as neat, but it’s typically compress it anyways and therefore won’t matter.

  145. Permalink to comment#

    I used to abide by the suggestions in this article from ThinkVitamin (http://css-tricks.com/new-poll-how-order-css-properties/), but eventually ditched it for alphabetical for two reasons:

    - no team debates on groupings, we all agree on what letters go where
    - it matched the same list I would look at in firebug and web inspector

  146. I become a fan of Chris Coyier after watching his “Lynda.com Tutorial”.

  147. mr. o
    Permalink to comment#

    Here is already app for group your rules nicely

    http://csscomb.ru/about/?lang=en

  148. Mine tend to be fairly random, although I do apply some kind of subconscious grouping to them. Styles for positioning, fonts, decorations etc tend to wind up together; mixins always come at the top.

    I’m sure I should probably start to be more strict about it, though.

  149. I try to group by type, but it usually gets a tad random after a few revisions.

  150. Ben
    Permalink to comment#

    I think this debate is slightly nutty, for two reasons:

    1) For people who do organization by ‘line length’, a question: what about vendor-prefixes? Don’t they make the lengths longer than that of the unprefixed declaration, ruining the visual integrity of your beautiful shaped code? :\

    2) For people who do ‘type’, that’s cool. But what about when a transition affects one property and not others? Personally If I’m transitioning a box shadow only, I want that transition declared next to the box shadow. Also, it’s hard for me to grasp the idea that margins and padding don’t affect “positioning”. Seems like an arbitrary grouping.

    @gib: Yes, there’s not arguing with the alphabet. It seems a lot simpler, for when things get lengthy. Less wandering around hunting for things. And it’s how inspectors tend to think.

  151. I do grouping when i’m writing custom stylesheets.

  152. I group them by specification chapter and property-value pair. Then I order them by specification chapter.

    http://fcpeic.cat/estil-screen.php

  153. Mostly Random, but i liked the length type css, its crazy for me :)

  154. For me, grouped by type is the best.

  155. order the css is not necessary, but the order does help and do our job well

  156. Random for us :)

  157. pixelutely
    Permalink to comment#

    In this order:

    1) Grouped by structure / functionality, helper classes last. Each group annotated with a header & some meaningful explanation.

    2) Within each selector, generally this is the order I use.

    a) display type (where required)
    b) dimensions, margin, padding
    c) background
    d) borders
    e) fonts & foreground colours

    I always use shorthand and, where possible, minified CSS.

  158. I try to use this order most of the time :

    1) display/position
    2) background
    3) width/height
    4) font/colors/etc
    5) margins/paddings
    6) borders/border radius
    7) misc

    Consistently using this helps me easily find the property i am looking for.

  159. Really, I’m kind of random. I do a lot of live editing in Firebug and it reorders my properties once I’m done editing. So after seeing that so much, I’ve started to order them the way they do. I have to do my own thing sometimes, though. They tend to break things up that I believe belong together… for clarity reasons. Overall, I’m not too picky with it.

  160. Weby

    I mostly order my css in a logical order, and make it similar to some firebug etc. displays.

    First the dimensions in the order which firebug and chrome display when you inspect the metrics of an element:
    Width/Height, padding, border, margin.

    Then the positioning (depending on the element sometimes I switch these two) with position, coordinates, z-index.

    Then some options like line-height, font-size, font-weight and stuff. And last but not least the background-stuff.

    Honestly for me the metrics and the positioning/display options are the _main_ options for an element and the background is the least important, so I really can’t understand how ppl can not have the metrics and positioning (the elementary options!) at first.

    But i’m several years in this business now, at the beginning I also had my css mostly “random”.

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".