I know this has probably been discussed before, but I’m not sure if it’s been covered as a single topic, and I’m curious to hear what people have to say.
What do you think is the best way to group or organize your CSS properities? The way I see it, there are basically three ways to do it, each of which I briefly describe below.
(Be sure to comment if you have a preference for any particular property ordering method, and your reasons for it.)
1. Group Similar Properties Together, Ordering Them Logically Within Each Grouping
This type of ordering/organization would look something like this:
.element {
color: #fff;
font-family: Georgia, "Times New Roman", serif;
font-weight: bold;
line-height: 20px; /* typographic stuff ends here */
width: 300px;
height: 300px;
position: relative;
top: 20px;
left: 50px;
z-index: 9; /* positional stuff ends here */
}
So the idea here is that the positional type stuff is all grouped together, as is the typography-related stuff (as indicated by the comments in the code). Properties like “width” and “height” are ordered logically one after the other.
2. Alphabetize Properties
This is exactly what it implies. The same CSS declaration block shown above would look like this:
.element {
color: #fff;
font-family: Georgia, "Times New Roman", serif;
font-weight: bold;
height: 300px;
left: 50px;
line-height: 20px;
position: relative;
top: 20px;
width: 300px;
z-index: 9;
}
I’ve personally never intentionally used the above method to organize my CSS properties. More on that below.
3. Do Whatever is Fastest (Deadline and/or Laziness)
I think this method is more popular than a lot of us would admit, but basically it’s the do-whatever-my-brain-says-is-next ordering method to ensure a deadline is met, or to just plain be lazy.
You don’t expect a code example for this method, do you?
Why I Primarily Choose #1 Mixed With #3
Firstly, I’m already anal enough about CSS organization (although my stylesheets probably still look messy to some); so I don’t need another vice. I also cannot see the benefit in ordering CSS properties alphabetically. It seems extremely counter-productive. Where is the logic in listing height before width, let alone listing width five lines below height? I do admittedly like to see z-index listed last, but other than that, I can’t see any benefit to alphabetical property grouping.
I suppose you could do a combination of #1 and #2, to ensure things are grouped but still somewhat alphabetized.
But generally, I can’t imagine typing up a declaration block of CSS, then going back to re-organize it alphabetically. Are there any text editors or IDEs that do this for you? I suppose if it’s done automatically, I could live with it, but I still can’t get on board with separating width/height, top/left, and other similar property pairs. If for nothing else, it seems to me that alphabetizing the properties is just going to make code maintenance harder.
Also, the reason I don’t strictly use #1 is the same as one of the reasons I don’t alphabetize: It takes too long to go back and reorganize each block, but I suppose the benefits might be worth it since (in my opinion) maintenance would be easier.
What Method Do You Use?
<
p>What’s your input? Do you use alphabetical property organization for your CSS blocks? If so, how do you justify it? Does it benefit your workflow? I’d love to hear from those who support using alphabetical ordering for CSS (mostly because I think you’re crazy :-).
I try to follow #1, but often the results are closer to #3 =/ (especially with personal projects, to lazy to clean up my CSS).
I can’t remember where, but I once saw a designer that ordered properties by the length of the property names.
I think I know the guy you mean; I’ve been cleaning up a lot of his stuff lately. He seems to have had numerous disciples; I can’t believe all this crap was written by one person, but oh well.
As far as I can see, the only reason anyone would ever use #2 is if they didn’t trust the search function in their text editor. Considering that every text editor I’ve used since at least WordStar 3.0 has had that feature nailed, I don’t have much sympathy.
Anybody else having problems with this form using Chrome 8 dev?
I place any sizing / position related properties together, in a different css file. In this way, when the site is translated to another language, and the sizes needs to be changed, it is possible to easily add a “theme” for another language (German words are usually longer, Chinese are shorter, etc.)
I separate them by CSS module and have each part alphabetical except where it makes sense to keep things together such as height followed by width
I always try mix #1 and #3, but mostly my way is #3 :)
I usually try #1, but often the result is a mix of #1 and #3.
#1 is more readable and easy to edit: it’s more logical to find font properties grouped with font properties, and so on
Generally, I do my best to follow method 1, but some times I just can’t be bothered to think about this all over again, so I just leave them as I thought of each property. :-)
I don’t really see any (feasible) logic behind method 2, either.
I start with #2, but by the time everything is tweaked, it’s more like #3.
I use #2 but I already know by myself I’m a little crazy :)
I find this method comfortable because I have worked with people with very little knowledge of CSS who used to mess up my work and it was easier to teach them this way :D
Secondly, I use a lot Firebug, which put the properties in alphabetical order.
So, after more than two years using this method and analyzing other websites with “Inspect Element” (now with Chrome too), it’s automatic, easy and fast for me and my eyes automatically catch what they are looking for.
I write my css declarations on single lines, since I scan for dec’s vertically, then horizontal to the property. To make this easier on myself, I alphabetize.
Additionally, after grouping my css into blocks for header, body, footer, etc., I usually alphabetize the css dec’s themselves, allowing for order of execution.
I alphabetize, however I’m not super strict about it. I’ve been doing it for a couple years now and its to the point where I do it naturally and its just as fast not alphabetizing (even when i started it didnt take that much time) I will say though I do really like have them in order. I can scan through my css much faster after its in order and that time saving greatly outweighs the time to alphabetize in the first place.
I suppose when you first scan a block of CSS, the alphabetizing would be beneficial. But once you find the property you’re looking for, if you need to find a related one, it seems more useful to have them grouped by similarity. Otherwise you almost have to scan the whole thing all over again.
But of course, we’re talking about milliseconds of scanning time here, so it might not be a big deal either way.
I’m an alphabetizer… I’ve done it for almost a year and now it’s pretty natural. It’s also make scanning my properties way faster. Especially when comparing to Firebug. But I try not to be to anal about it. Just as long as the first character is in alphabetical order…
That’s actually a good point, that it keeps it similar to Firebug’s ordering…. Interesting view….
I usually write my css on single lines as well, the order? well that depends… In most websites stylesheets I use #1, and I try to keep similar properties together in order of importance, that is first what may affect the layout and then what affects that particular style element… But in apps is different. Because they need to be easily transformed from one design to another, I order them in what i call “chance of being changed” order… that is, for example, color, border, font, background, and the last items would be the structural ones like height, width, position, margin, padding, etc…
Without a doubt: alphabetize. It’s quite natural, and really not that difficult. Looking at properties that aren’t alphabetized sort of does my head in sometimes.
#3 then run it through http://proCSSor.com/ to prettify it? I believe proCSSor will allow you to specify how you want your CSS cleaned up as well as just single-click it for you. It looks like they don’t have their sort properties feature in there yet but hey, step in the right direction.
I think it does, just try disabling ‘fail-safe’ mode.
Always single line and with the most basic / unchanging ones first but with similar properties grouped.
I use #2, because I know I will not always be the only person working on the files. Just like how we’ll all have different opinions on the way to organize, three people will have three different opinions on logical groupings. So, in my little dream world, everyone would do #2 and every site would have the same flow.
But how do you justify having “width” nowhere near “height” in some instances? Don’t you think it’s a little counter-intuitive that way? I just don’t see any “flow” happening from keeping similar property pairings away from each other like that.
For example, if you create an HTML <img> element, would you group the attributes like this:
<img alt=”Example” height=”300″ src=”images/my-image.jpg” title=”Example” width=”400″ />
It just makes much more sense to put “src” first and keep “width” and “height” together (with width ahead of height, the way most software interfaces do it).
But thanks for the input; I suppose your reasons for doing it are understandable and do take into consideration the bigger picture.
It’s all subjective really. The flow comes naturally after you’ve done it a few times for creating the properties. The magic comes in finding and editing stuff later. It’s so much faster. For small things, it’s not a big deal, but when you come across a beast like the sample below, I wouldn’t have easily found letter spacing and I wouldn’t really be sure where to add a border property logically. However, if they were alphabetical, I would. It’s just a matter of different strokes for different folks…
Sure, use my own sloppy code against me! :)
Good points, Dan, I appreciate you taking the time to give your feedback. A few comments here have helped me see why people use alphabetical (but I don’t know if it’s enough to convince me to use it).
(Not to mention that you reminded me how poorly code within comments displays on here, which I just fixed….)
Yeah, I’m sorry about that! I wasn’t sure if it was going to display right. This is a great post and discussion. I love learning on the reasoning behind practices that people use. Plus, I could talk about markup all day…
Personally, I use #2. As it will be easier to be read in the future.
I can scan it faster when I want to find something.
But in some case, I use #1 with alphabetic order for each group.
I think everybody must group CSS properties according their priority, for example, “float” or “display” is stronger than “color” or “-moz-border-radius” : )
I might be too timid in approaching this, but I would have a hard time making that decision. For example, where do you put line-height? It’s technically typography related, but also has a strong impact on layout.
Also, I would tend to group border-radius with layout functions like float and display. So, you’d jump into my code and be like “what is this goofball thinking’?
Sadly the priority for me ends up being #3 > #1 > #2
I find myself in a hurry most of the time, trying to meet a deadline. I ALWAYS group my properties though. Though I tend to put mine on the same lines to shrink my code a little as I go.
I use #2 solution, because it is fast when you use it all the time, and becasue it’s kiss(keep it stupid simple)able for other persons working on the same project.
I don’t use any method other than whatever flows through my head at the time. I make extensive use of firebug for testing/debugging which I know alphabetizes the CSS, but all in all, I don’t really care. I edit CSS written by others using all kinds of structure and I can adapt to whatever format the original used. I just don’t find it all that difficult no matter what order the properties are in.
I tend to group multiple properties on to one line using #1, and then order those lines in a somewhat arbitrary yet consistent order that makes sense to me”
margin, padding
display, float, width, height, overflow, etc.
position, top, left, z-index, etc.
font and text stuff
backgrounds
borders
border radius
box-shadow
CSS3 transforms
CSS3 transitions
The CSS3 properties get their own lines because of all the different prefixes.
I like your structure, but I would factor in commonality and give that priority (ie: placing width/height above margin/padding), and while I understand your reasoning for separating CSS3, I find it works better to include it with similar properties (ie: border width/style/color with border radius; font family/size/weight/style with text shadow; etc.).
It seems to me that I set margins and paddings a lot more than I set the width and the height, but I guess that’s just a difference in the way we lay stuff out. I also vary the order sometimes from project to project, for example, if I’m working with a lot of em units, the first line is usually font-size, all by itself, with a comment stating how many pixels an em is for the rest of the properties.
I keep the prefixed CSS3 rules separate because I don’t write all the prefixes as I go. Once I get something working in the browser I’m testing in, I add the rest. Having them at the end and each on their own line makes this step faster.
Categorized grouping is more ideal. I start with structural (dimensions, margins/padding, border, background, etc.), then go to positioning (display, position, float, etc.), and finish off with text (font, size, weight, style, alignment, transformation, line height, etc.).
Hi,
I group mine from macro- to micro- properties, ie layout stuff first (eg display, z-index, position, floats, text-align centering hack), then dimensions (width, height, padding, border stuff) then font stuff and background colour. Lastly, specific browser extension rules (-moz-blah).
I found this to be a sane way to organise as you intuitively know which third of a rule block to look to and don’t have to scan every line. Most likely this was written about on Alistapart 5-6 years ago and it worked so I stuck to it.
Seems us categorisers are in the minority!
I think alphabetically (#2) serves no benefit. It takes longer and really doesn’t help you or anyone else who may touch a website after the project.
I typically try to follow #1 as much as possible but ultimately time is money so #3 is always what it ends up being.
It’s fastest for me to do alphabetical. It requires no thinking — no “should this be grouped?” And when I have to go back and change something, it’s almost instant knowing where to find it. This is especially true with properties that I don’t use very often. So to say it doesn’t help me or anyone else is broad and incorrect.
Now, having said that, I have no problem with people going the route of #1. It makes sense, too, so if you prefer it, use it.
I definitely start off as #1 but I usually end up doing #3 because of ongoing tweaks and changes.
I follow strictly #2 and i’m cool with it :) once you stick with it it becomes the fastest way imho
#3
I use my own method:
position
float
dimensions (width, height)
margin
padding
oder stuff
font info
color info
I think following always a method is good so you’ll always find things quickly. Personally I prefer this one cos the stuff I find myself editing all the time is usually related with positions, dimensions, floats, margin and paddings.
Great article. I always write my css alphabetically for a couple of reasons, speed and it also helps in the editing/modification process because you don’t have to search all over the place for a attribute, you can just go in alphabetical order.
I think categorically is really a natural brain flow. Alphabetically would be very interruptive and time consuming definitely defeating the deadline goal. You consider each element or section one at a time and style that element according to what’s inside. For instance, a div with a paragraph and a picture. I would probably first style the div itself if need be, then the paragraph’s properties then the picture. If I wanted to be anal as to comment those various parts it would be even that much easier on me or another designer who might work on it if things were list categorically.
Wow, I am actually surprised by the number of people who are admitting to #3.
I use my own method….size, positioning, float, margin/padding at top, all other crap slapped at the bottom. Where a property is in a style doesn’t speed or slow things down for me. Where a particular style is, does. Thank god for firebug, and most IDE’s Go To Line command, or it would be a long process.
When it comes to properties, I never look at the design in the browser until the basic structure is laid out. So all my css is ordered in the order the containers go:
Header
Nav
Content
Sidebar
Footer
Then I go in and add all the detail stuff.
I use the order below:
I naturally do #1, peppered with some #3.
I generally don’t think about it, though. If the definition gets really long, which rarely happens, I might reorg. Most of the time definitions aren’t longer than 8ish styles, and I’m spending time to organize at that point isn’t worth it. It’s not hard to find what you’re looking for over 8 lines.
Whitespacing is more useful. Let your code breathe and you’ll be less likely to be overwhelmed: http://www.impressivewebs.com/css-readability.
Method #1 in multiple lines. Usually I try to order the properties by strong-to-weak:
– location-related and layering
– size
– margins and padding
– font related
– text related
– beautification (backgrounds, borders, round corners, shadows)
Doesn’t always work, so sometimes it looks like #3. :-)
I actually use exactly the same structure. It’s nice to feel validated. (no pun intended)
Organizing selectors is required, but if you spend any time trying to organize your CSS properties you are spending time on the wrong part of your project.
It is rare that you will have an element that has more properties than are visible at a glance. No one searches CSS properties by alphabetical order, they just glance at it and see the style they want.
Also, I would highly suggest one-lining your CSS styles. People who keep it multi line often haven’t worked on large projects where CSS files become larger and having multi line styles make it very difficult to navigate the CSS file. Keeping your CSS one line makes it very easy to scan styles and find the element you want, especially when it is logically organized by section.
Also, the more vertical reading you can do in your text editor the better. Multi line simply wastes editor space. Just say no to scrolling ;)
Come on, guys. This totally doesn’t matter.
Actually it does.
if there are less than 6 properties I put it on a single line, otherwise group in 5 groups:
#selector {
layout (float, position, padding, margin, width, height, line-height…)
appearance (background, color, text-shadow, box-shadow…)
typography (font-family, font-size, font-weight, text-align, text-decoration…)
css3 (border-radius, gradients…)
transforms (transform, transition, animation…)
}
I usually use #1 but I’m thinking of switching to HSS. It’s a command line CSS compiler that takes a HSS file (CSS + support for nested CSS & variables) and spits u back pure CSS. What do u think of this?
I always write all my declarations on a single line and I don’t use any specific method other than whatever comes to mind at the time, but I do however prefer to have the background property at the back.
Very interesting read! Recently on new projects I’ve become rather anal with my CSS properties and started to use a mix of one and three – however, within the actual style sheet I put all header things first/then body and finally footer. Then within the properties for example when you round corners on divs I define top things then the bottom! Whether it’s true or not one drunken night someone told me a page loads top down! And it loads faster if it doesn’t have to keep shooting up and down the CSS page getting styles! Any truth in this or has me anal retentiveness been subconsciously furled by vacuous wonderings????
Not coming from a programming background I cannot fathom having your declarations on a single line. I have a strong Graphic Arts background, and when working on projects that can utilize many classes & ID’s you need to be able to get-in and get-out. Readability is key. Working for a large platform yields me both options, and I have tried to live with each. Any more than four properties and your eyes have to do extra work. When you consider this on a daily basis 8,10+ hours a day you’ll feel the strain. Multi-line can lessen the blow. I’m also naturally lazy.
I’m all for #2 – not only does it require little-to-no thinking as to what should be grouped with what as others have pointed out, but as an added bonus, having properties listed in a consistent order will give you better a compression ratio. It sounds crazy but it’s true!
I’m faced right now with hacking phpBB’s style sheet to get the look I want. 4000 lines. Yikes.
I’m looking at font-family: declared 29 times. color or background color declared 450 times with 126 unique values, 55 of them grey.
One of the ways of sorting through the mess is to regroup by attribute. Example:
h1 {font-family: times; font-size: 2em; color: FFF;}
h2 {font-family: times; font-size 1.5em; color: FFF;}
h3 {font-family: times; font-size: 1.25 em; color: FFF;}
turns into
h1, h2, h3 {color: FFF;}
h1, h2, h3,{font-family: Times;}
This allows you to see where a given attribute is used. I think I can write a perl script that inverts the format back and forth.