Noupe Editorial Team November 10th, 2007

9 CSS Ethics Every Designer Should Have

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.

Tags:

56 comments

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

    Reply

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

    Reply

  4. 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 rule onto it’s own line?

    On number 4, I am mixed on this one. Using import statements, and chunking your CSS into different files is much easier from a development standpoint, especially if you’re coding on a project where multiple people may use it.
    However, performance wise, it’s a really bad idea, because it requires a separate HTTP request for every file, and the HTTP spec says that only 2 requests can happen simultaneously.

    The optimal solution would be to have a server side script that either builds all of the files into a minified one file for production, or a script that compiles them at runtime and caches the result.

    Otherwise, though, great article :)

    Reply

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

    Reply

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

    Reply

  7. 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 { }
    Reply

  8. 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 maintenance more difficult.
    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.

    Reply

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

    Reply

  11. 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 and a good code editor, I don’t find long files a problem to deal with.

    8 I can’t be arsed with, and don’t see the point, and 9 is just wrong IMHO. Using class names with things like ‘left’ or ‘red’ is a bad idea.
    Using class names that relate to the content of the object, not how it is rendered. Don’t forget alternate devices, when on a mobile phone, ‘right’ might not have much meaning…

    Reply

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

    Reply

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

    Reply

  14. 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 example, if you have a container, header and footer that drive your layout, group them together.

    I hope this makes sense to you and all can be optimized later in one file when placed on server to reduce the number of HTTP requests to lighten the load on your server.

    Reply

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

    Reply

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

    Reply

  20. 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 another site and need to change properties in all of your sheets.

    I say this as someone who has been using the method for over a year now. I regret using it now.

    Reply

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

    Reply

  23. 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 not fit on the (half) screen and i have to scroll left and right. There is a reason that programmers have a well-established convention that a line of code should be not much more then 80 characters wide.

    Also, not following #1, #2 or #4 because “it will waste bandwidth” is not a good reason for me… There are tools that can compress and merge css files.

    Reply

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

    Reply

  25. 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:
    http://onerutter.com/css/css-naming-standards.html

    Reply

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

    Reply

  30. 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 a nice job of saving valuable bytes, as well as cleaning out comments.

    One of the properties of the .cssx file is cache control – it allows the developer to set different files to have different lifetime’s.

    Combine these features with server-side gzipdeflate and you will save yourself alot of valuable bandwidth.

    Reply

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

    Reply

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

    Reply

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

    Reply

  36. Mario, Karim

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

    Reply

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

    Reply

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

    Reply

  40. 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 is getting really tired. Everyone is different, works on different projects and has methods that work best for their particular situation. To say that you have “THE” way to do things is arrogant and presumptuous.

    Reply

  41. 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 to edit.

    Reply

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

    Reply

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

    Reply

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

    Reply

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

    Reply

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

    Reply

  50. 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, obvious, and expedient. They are best used in tags, not divs, For example, <img class=”alignRight” and <div class=”menu” both are descriptive.
    Good article. A good dialog to start.

    Reply

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

    Thanks
    Nikos

    Reply

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

    Reply

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

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *