9 CSS Ethics Every Designer Should Have

No Picture

No need to get any more complicated structure than you need to. Writing a CSS Stylesheet That is Easy to Maintain is really easy, just by following these 9 rules.

How deeply  you organize your CSS can greatly hinder any necessary tweaks that arise in the future. So, I proposed the question to my team to take a close look at some of the most interesting CSS coding structure and listed them below where you can probably use in every project you are developing.

1) Indent descendant and related rules:

This allows you to easily recognize page structure within your CSS and how sections related to each other. [Erratic Wisdom]

  1. #main {
  2. width: 530px;
  3. padding: 10px;
  4. float: left;
  5. }
  6. #main #nav{
  7. background: #fff;
  8. width:100%
  9. }
  10. #main #left-col {
  11. background: #efefef;
  12. margin: 8px 0;
  13. }
2)Grouping and commenting your CSS rules

Setup certain sections in your CSS files that always exists: page structure, links, header, footer, lists, etc. Those sections are always CSS commented to name each section appropriately.

  1. /* Header Styles Go Here **************/
  2. ...CSS Code Goes Here…
  3. /* End Header Styles *************/
  1. Header
  2. Structure
  3. Navigation
  4. Forms
  5. Links
  6. Headers
  7. Content
  8. Lists
  9. Common Classes

And a sample separator that is most easily noticeable

  1. /* -----------------------------------*/
  2. /* >>>>>>>>>>>>> Menu<<<<<<<<<<<<<<<<-*/
  3. /* -----------------------------------*/
3) Keep style type on single line

Combine properties onto a single line by using shorthand properties means that your CSS will be easier to understand and edit.

Instead of this:

  1. h2{ color: #dfdfdf;
  2. font-size: 80%;
  3. margin: 5px;
  4. padding: 10px;
  5. }

Do this:

  1. h5{color: #dfdfdf; font-size: 80%; margin: 5px; padding: 10px;}
4)Break your CSS into sheets

Separate your CSS stylesheets for different sections, use one stylesheet for layout, another for typography and another for colors .Mixing layout / typography properties will make you find that you are needlessly repeating yourself.

  1. #main { @import "/css/layout.css";
  2. @import "/css/typography.css";
  3. @import "/css/design.css";
  4. @import "/css/design-home.css";
  5. @import "/css/extra.css";
5)Reset your elements

Many designers clear the styling of their sheets with a global reset which has an impact on some elements like form buttons and fieldsets that are completely destroyed with the global reset.Instead, you should pick-and-choose the elements you want to reset.

So instead of doing this

  1. *{ margin: 0; padding: 0; }

Do This

  1. html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {
  2. margin: 0;
  3. padding: 0;
  4. border: 0;
  5. outline: 0;
  6. font-weight: inherit;
  7. font-style: inherit;
  8. font-size: 100%;
  9. font-family: inherit;
  10. vertical-align: baseline;
  11. }
6)Place color scheme in one place for refrence.

Before you start your CSS file, comment your common colors and add it to the top of your style sheet.This will save you ton of time and will insure that your site has one color scheme.

  1. /* Colors: Dark Brown #473B38 Light Blue #A8EFEE Pink FF4095 */
7)Use a meaning naming system.

Having a naming system for classes and id’s saves you a lot of time when updating your document or debugging, you can use parent/child structure. The parent would be the container. So if our DIV is named “header”, and two divs nested called “menu” and “logo”. The naming structure in your css would be:

  1. #header #header_menu #header_logo
8)Alphabetical Properties

It makes specific properties much easier to find.

  1. body {
  2. background:#fdfdfd;
  3. color:#333; font-size:1em;
  4. line-height:1.4;
  5. margin:0;
  6. padding:0; }
9)Keep a library of helpful CSS classes.

Useful for debugging, but should be avoided in the release version (separate markup and presentation). Since you can use multiple class names, make use of them debugging your markup.[Richard K. Miller]

  1. .width100 { width: 100%; }
  2. .width75 { width: 75%; }
  3. .floatLeft { float: left; }
  4. .alignLeft { text-align: left; }
  5. .alignRight { text-align: right; }


Keep it Simple

No need to get any more complicated structure than you need to. Simplicity will save you time and efforts.

It would be great if you share with us your organizing tips to make this post a refrence to many of us. Don’t forget to mention your site and name as it will be mentioned below your tip.

Noupe Editorial Team

The jungle is alive: Be it a collaboration between two or more authors or an article by an author not contributing regularly. In these cases you find the Noupe Editorial Team as the ones who made it. Guest authors get their own little bio boxes below the article, so watch out for these.

Sort by:   newest | oldest | most voted

good info, really useful.


I couldn’t understand some parts of this article nnial 2007 – salvatore iaconesi – del.icio.us poetry, but I guess I just need to check some more resources regarding this, because it sounds interesting.

Greg Correll

Loading multiple style sheets slows down your site. We reduced from 5 to 1 at a large financial site and saw a 10% + decrease in page load time.

Nate Cavanaugh
I like most of your suggestions, but I have to take issue with numbers 3 and 4. On number 3, maybe there is some sort of mental block on my end, but I can’t imaging how having all of the properties on one line is easier to understand or edit. It’s much harder to find a single semicolon in a line of text to find the delimiter than it is to just see all of the rules on their own line. If it is in fact easier, why do all of your examples use the traditional way of placing each… Read more »
Matt Rossi

I would have to agree with Nate on #3. To me personally it is much easier to have my styles broken up with a break in between. The great tip you had in #8 would really be pointless if it weren’t broken up.

I think you should apply the same principle that I discussed (breaking lines between styles) with the color glossary.

I really liked #1 and #8, great points. Overall good article, straight to the point. Nice site by the way too, very easy to nav. Take care!


Nate, Matt: I moved to this method after my CSS files started getting ridiculously long. For me, the most significant advantage is the ability to immediately see the relationships between parent and child elements , it just seems easier on the eyes, especially as you have more attributes and such.

All of this can change when it goes to a live server – it can be optimized and compressed for that, but for development I like to be able to see it all.

It all comes down to a matter of preference and what works for you…

An example of using Indented Single Line for parent and child elements is like this: div#navigation { } div#navigation p { } div#navigation ul { } div#navigation ul li { } div#navigation a { } div#navigation a:hover { } div#navigation a:visited { }
Nate: If you create a frameworks of multiple CSS files and concatenate them in one long file, server-side, you are saving the HTTP requests and lightening the load on your server. I agree with you that this method on large, high-traffic sites, adding five more HTTP connections to every page view may result in angry system administrators. Kevin Cornell suggests two possible solutions to this are: 1. Include everything in a single file, rather than breaking it into modules. The problem here is that you lose the ability to include only certain parts of the framework, and you also make… Read more »



I don’t agree with #4. Dividing your CSS in separate files increases the web page load time. The page load faster if it has reference to less external files (JS, CSS).Also keeping the file size small reduces the data being transferred.

Hmm, I can’t go along with 3 and 4. 3 I find harder to read, and page length I don’t find an issue with due to using firebug a lot and a half decent code editor with good syntax hightlighting and line numbers. 4 I find you end up having to remember which file something is in. You get to the point of needing to make an amend to one area, but editing 3 files to do it. Or being lazy and sticking the amend in one file, and then struggling to find it later. Again, with tools like firebug… Read more »

Ofcourse the ethics are gud but it will bloat the style sheet and increase the loading time.

When normal optimisation techniques are for a minimum number of stylesheets , the ethics show otherwise

Chris Olberding

I do think it’s a choice of style but I switched to writing my styles on a single line about a year ago and can’t imagine going back. Cuts down on the length and file size of the style sheet too. I try to maintain two sets of style sheets, production and development, the production set is optimized and all lumped together in a single css.

zParacha, Adrian and Kingstone When building a large site, I really like the move to separate module CSS into separate files – this makes maintainance and overriding much easier. You don’t have to create like 10 style sheets, 3 or 4 is fine as long as you separate the style in a good manner like putting defaults like fonts, anchor colors and behavior, headers, and any other properties that all pages will share in the default CSS file. The best way to group rules and selectors is by their relationship to each other and the rest of the page. For… Read more »

This is exactly the best thing, just optimize when placed on server on one single file.

anton darmawan

very beautiful


2. Have a server-side process that dynamically flattens the individual files into a single response. I’ve not seen this done, but it could be very efficient if done well. This way, the individual components are still available, but the entire framework is available in a flattened version, as well.

For WordPress users there’s a plugin called WP-CSS-Streamliner that does exactly that. When it works, it’s awesome, but some hosts seem to have porblems with it. My Mac testing server works flawlessly, but my web host spits out an error when it’s turned on.

Mia Tyler

Hi there…i just love your blog, keep the cool posts

Nice set of tips but I have to go with many of the other commentators on points 3 and 4. Single line formatting of attributes seems to lead to less readability for me. I also found out the hard way that, although separating your sheets by function seems to be a good idea, in practice it just leads to a lot of going back and forth from sheet to sheet having to find and tweak the same tags or id’s over and over. It becomes pretty unwieldy after a while, particularly when you want to port the sheets over to… Read more »

Sorry, I can’t agree with “Break your CSS into sheets” since another rule in optimization recommands to have the least possible. And it’s right.
Secund, the “separator” comments make sheets ugly and almost unreadable sometimes.

Thomas Neumann
Very nice list, I agree but I cannot really go along with #3… I’m actually a backend web-programmer and not a css designer and in a current project I have a quite hard time with css files that use a single line instead one line per attribute: Even though it may read better when editing, it does not work correctly in a standard version control diff and merge (CVS, Subversion, etc), as most of those tools work per line. Even with decent diff-editors that work per-character I’m having problems when comparing or merging 2 css files because the lines will… Read more »

I’m not sure I see the sense of arguments against chunking out your css into multiple using @imports. Sure, this impacts the load time of the first page served, but then they’ll be cached. We could time it, but I suspect that forcing every user to pull down all the styles used in every section of a large site is just as slow as having them do a few requests for small files (especially when they may not even visit some of those parts of the site).


I agree with Noupe and Chris Olberding for number 3 — I, too, went to single line styles a while ago and also cannot imagine going back. My stylesheets are easy to scan, it’s easy for me to find the thing I’m looking for, and they are a LOT faster to write now that I’m not having to do all that formatting.

Jake Rutter

Nice list, but like the others I dont agree with putting all your attributes on one line, when you could just combine all the font attributes into one declaration like:

font: 12px/14px “Helvetica Neue”, Arial, Helvetica, Geneva, sans-serif;

I would also recommend that you indent all your styles, it makes everything look so much more organized!

As for naming standards, I put together a great article on what to call things:


I actually think css is overrated. There will come a time when separating everything arbitrarily will work against us.


I’ve been doing most of these for a while, even the alphabetical ordering of properties and indenting of selectors, but I don’t think I’ve ever seen these things all written down in one place.

Good work.


Hi Noupe, nice tips and nice site.


#6 was the only useful one.


h5{color: #dfdfdf; font-size: 80%; margin: 5px; padding: 10px;}


Bryan Migliorisi
While it is nothing new, I have created a simple but powerful CSS server-side framework in C# that allows me to specify one .cssx file that concatenates all of the referenced .css files – and does some magic along the way. Its great because it allows me to have each set of styles in separate files for easy understanding without the extra HTTP overhead associated with multiple GETs. It supports server-side variables which makes it simple to update colors, and other common attributes. It also uses the exact same compression algorithm found in YUI’s CSS Compressor – so it does… Read more »

Number 9 is blasphemous. IDs and class names define element roles, not presentation.

Nancy Odell

Hey!…I Googled for sing down the moon by scott o dell, but found your page about o.us poetry…and have to say thanks. nice read.


Great article on CSS Coding structure, good stuff to share :)

mark rushworth

i hate when css goes onto more than one line… it makes it really hard to read. instead i keep each class etc all on one line and use tabs to show grouped information… works well for me.

Adam Bezulski

3) Keep style type on single line??????
for me it is better to keep in separate lines.

Keeping style in one line makes me confused


Mario, Karim

Optimizing for a server is very different, but when developing locally, this really speeds up my development.


I have preferred this method for a couple of years now. I remember first seeing it on a previous incarnation of Ryan Sims justwatchthesky.com and I thought it was rather hard to read. Now, I wouldn’t do it any other way.
I think it all comes down to what is easier for you to manage.


I prefer multi-line for organizational purposes when coding by hand, but the best use of the single line selectors method is used by Panic on the Coda app.


Thomas Neumann
But maybe if you use this way your files might not need vertical scrollbars. :)

There are a few valid tips here but I have to agree with the others about 3 and 4. Everything jammed up on one line makes it far more difficult to read and find things. Having separate lines with indentation is much easier. I separate the main style sheet and the print one but never by section or type. Way to difficult to keep track of, too many calls and too many files to have open while editing. I found #2 and #5 to be the most valuable tips. Also, this whole “every designer should do this” type of article… Read more »
I think Thomas means that he is getting a horizontal scrollbar as he says he is forced to scroll left and right. Using the method described in #3, you will very easily get a horizontal scrollbar since the line can get very long very quickly. Personally, I would rather scroll up and down instead of left and right, especially since the scrollwheel on my mouse doesn’t support horizontal scrolling and I would instead have to navigate around my document two different ways: up or down to find the style and then left or right to locate the property I wish… Read more »
Alexander Geßler

Great article! Thank you for the unique approach. In CSS you often do not know where to begin. Clear guidelines are fine!

Thomas Neumann

@Noupe: Generally, I’d always prefer a vertical bar over a horizontal. , but that’s not the point i was trying to make – the point was that many tools (esp. diff and version control system, also some editors) do not work very well with long lines. Also when you have an editor that wraps lines instead of making a horizontal bar, this will make your css file look like a big pile of character junk.


The idea behind #1 is relatively new to me and I must say it doesn’t sit well. This technique seems to run afoul of the separation of style from structure I hold so dear. I fully support a need for oder but I believe this is better handled through good logical grouping and sensible comments. (#2)


The idea about this post is to give different ways of organizing your CSS code and files, some people use all of these directions , other prefer to just use 3 or 4 ways others just use completly different ways of organizing their CSS, it’s realy a matter of personal prefrence.
If someone have other css organizing tips, please feel free to post it here.


Wau!! I knew some thing but there’s always new! great tutorial! thanx!!

Officer G

Short hand CSS is craking eg – padding: 0 0 0 0; But I’m not sure putting everything on one line makes it easier to read?

Cory Perry

Great article! I already implement several of these suggestions but this still a great list!


Very useful tips. thanks for sharing :)

John Sinclair
Item #3 — one line is easy to read if your text editor or CSS editor gives you syntax coloring. But if I’m browsing style sheets on the web it is harder to glance and understand. Item #4 — multiple imported stylesheets are harder to maintain and I find I can lose track of cascades and inheritances. Items #1 and #2 — I employ. The slight overhead associated with verbose commenting is outweighed by the maintainability. And I always assume someone else will someday work with my legacy code. #9 — class names such as .floatLeft and .center are simple,… Read more »

For me the best rule is number 6. Due to my day job (SEO) I am checking lots of time checking on websites and so far I havent seen a CSS file using a comment with all the color’s values. Is a simple idea which can save a lot of time…


Eric Martin

Nice article, thanks!

I’d never thought about doing #1 – seems like a good idea.

I switched to #3 a while ago and wouldn’t want to go back to putting every element on a separate line.

I used #4 for a work project and I have to say, I’m not a big fan. Mainly because it increases the number of server request and considering styles can bleed across functional uses, it can be difficult to organize correctly.

#8 is a good idea. I tend to group mine first by HTML elements (div, p, table, etc.) then according to the page layout.


Great article! Thank you

Dan Collins

Great tips!
Thankyou very much!


I agree with most of these, but this one about breaking stylesheets into few files I can’t agree. Just, when you’re doing a bigger website with few thousand visitors, it’s pretty much important not to make too many HTTP requests..


These are great. Bookmarked for later use!