10 Great Tips for Writing Better And More Comprehensive CSS

There are many different coding styles, some do not like indentation, some like to capitalize certain things, others like to add more than one element on a line, the main train of thought is they are all after one common thing: organization and better code.

Without influencing my coding style, we’ll discuss ten tips for writing better CSS. Let us know what you think in the comment section! See you there ;)

Comments

Writing Better CSS

Commenting throughout your style sheet significantly helps you locate certain code blocks of CSS quickly and efficiently. Imagine trying to search through a CSS file with hundreds of lines of code, it can take quite some time to get where you want. Instead, neatly organize your CSS code by grouping similar elements and describe the groups with simple comments. By doing so, instead of searching hundreds of lines of code, you can search through several grouping comments instead, saving you a lot of time locating certain code bits, as well as it keeps your code neatly organized.

Indentation

Indentation is another key to keeping your code neatly organized and easy to flip through. Having the rules indented from the classes and IDs makes it a lot easier to read the code and identify between them. These little things improve your code’s layout to make it easier to work with and modify in the future.

Shorthand Code

Writing Better CSS

I have seen many style sheets consist of non-shorthand code. Imagine having 350 lines of CSS code, if each class or ID consisted of five rules (so seven lines per class or ID), and utilized the shorthand margin rule, it will be less cluttered, neater looking, and easier flip through. Now take the shorthand margin rule and expand it to margin-top, right, bottom, left. That is three extra lines per class or ID, making the 350 lines of code to 500 lines of code, that is an extra 150 lines of unnecessary code making the style sheet cluttered and more difficult to navigate through. Therefore, use shorthand rules when applicable to save on clutter and speed.

One Line per Rule

One of the most irritating things to see is multiple rules written out on a single line as if the person who coded it was running out of lines and crammed everything onto several. Code efficiency starts with organization as organization leads to faster coding and navigation, which ultimately leads to performance. Therefore, separate your CSS rules line by line, as you are helping yourself in the long run.

Hacks Should Stay Out

Writing Better CSS

Separate your Internet Explorer hacks from your main CSS by creating separate style sheets targeting the different versions. By keeping your hacks mixed within the rest of your mainstream code, it is not only clutter, it usually is not valid code as well as it may cause troubles between different browser versions. Therefore, keep things neatly organized and rather simple by having browser version targeted CSS style sheets.

Meaningful Names for Classes and IDs

Many CSS coders including myself tend to sometimes throw some odd class and ID names when we are in a hurry to get things done. The problem with this is that later on when we need to modify our CSS style sheet, we would need to reference our HTML as well to figure out which class or ID belongs to what.

Instead, save time by giving your class and ID names meaningful ones that reference what they relate to, something you can understand down the line when you get back to it. For example, if you create a class that is styling a footer widget bar, do not name the class widget bar if you have others, but rather footer widget bar as it describes it exactly and when you get back to it at a later date, you will know what it is referencing exactly.

Eliminate Unused CSS Classes and IDs Immediately

Writing Better CSS

Many times, we tend to expire certain CSS classes and IDs we do not need to use anymore, but instead of removing the code from the style sheet, we tend to keep it in the file, which starts to accumulate with unused elements. By keeping the unused classes and IDs in the style sheet, it just continues to make it difficult for you to skim through the file and locate what you need to modify, and in most cases, it makes it confusing to identify between used and unused elements. Therefore, as soon as you no longer need to use a class or ID, it is in your best interest to remove it from the style sheet or, you can archive it in a different file if you feel you may reference it in the future.

Alphabetical Order

Another key aspect to keeping your code easy to work and manipulate with is to alphabetically organize your CSS classes, IDs, and or rules within them. This allows you to easily skim through the style sheet and arrive right at the class or ID you need to modify without much hassle at all. Additionally, alphabetizing the CSS rules within classes and IDs also helps keep things tidy and as well easy to locate.

Combining Selectors

Writing Better CSS

A great easy way to organize your style sheet is to combine multiple selectors if they have similar definitions or style rules. So for example, if you have li, ol containing similar style definitions, just combine them together into one to save space and to keep things tidy.

Split Into Multiple Files

If you are working on a rather large-scale project with countless amounts of CSS lines, it is in your best interest to separate your CSS into multiple groups in multiple files. This makes your work a lot easier and saves you time from locating CSS code blocks instead of searching one main file with thousands of lines. For example, you can split typography into one file and the main layout elements into another.

Therefore, if you need to modify or add to the typography style sheet, you can easily go to a file that contains just that without the hassle of skimming through other unrelated classes and IDs. However, if you are working on small projects, splitting your CSS code into multiple files might be overkill; thus, this method should not be used liberally across many projects small or large.

Your Turn To Talk

What do you think? Do you use any of those when writing CSS? How do you do it? What do you prefer? Please take a moment to let us know in the comment section!

Comments

  1. says

    hi,
    you have done this article nicely about css. Me too often time think it would be more helpful softwares like Dream weaver find and warned us about “Duplicated and unused” styles. After all it wont be a big deal for them. Besides if you tell us how to write css Alphabetically, would be a great help for us.

    Thanks
    Ravikumar V.

  2. says

    Not arguing against you on the “No CSS hacks” but this is a rather nifty way to do it:
    Shoot. Your comment form didn’t like html comments… hope it likes & gt ; better. Here is the code again:

    <!–[if lt IE 7 ]> <body class=”ie6″> <![endif]–>
    <!–[if IE 7 ]> <body class=”ie7″> <![endif]–>
    <!–[if IE 8 ]> <body class=”ie8″> <![endif]–>
    <!–[if IE 9 ]> <body class=”ie9″> <![endif]–>
    <!–[if (gt IE 9)|!(IE)]><!–> <body> <!–<![endif]–>

    Means you can add rules like:
    .content { width: 40px; padding:10px; }
    .ie6 .content { width: 60px; }

    So now you can put your styles together and it saves you from another http request.

  3. says

    I have to disagree with the “One Line per Rule” rule =) The thing I hate most about other people’s css I have to work with is when one ID or class has 12 lines and I have to scroll and scroll again when searching for the one thing I want to change.

    After years of coding I’ve developed an ability to quickly scan the lines and find the one rule I’ve been searching for without the need of separating it using another lines that are in fact slowing me down.

    Other tips, on the other hand, should be carved into stone (which every noob coder’s head should be hit with =))

    –DISCLAIMER–
    Pardon my lame English I’m European…

  4. says

    Some of these methods of Writing Better And More Comprehensive CSS are nothing but subjective opinions. What works for one person might not work for another.

    For example the one-rule-per-line-thing. For me that is the most irritating thing to deal with when taking on the work of someone else. It just makes the document too long with too many lines and it is hard to get an overview of the code.

    Alphabetical order is another thing. I think that the best thing to do is to group the rules that are related to each other starting with structural rules from the left and end with “less important” rules such as cursor, background and z-index.

    While my examples are subjective as well – and this is what makes me an efficient coder- there are things that you should not do no matter what. One of these things is separating code into multiple files (.js, .css). You should always keep the number of files to a minimum due to performance. Since a server can only download 2 or 4 files simultaneously from the same domain, you will have a performance issue if you load too many files in the header before you load the page structure.

    My suggestion here is to load only a maximum of three files in the header; your main.css, your main.js and if you use a js-library it could be an advantage to load it from a CDN. Instead you should structure your code in such way that it is easy to follow. Then it does not matter if the file itself has many lines.

    One thing I really agree with you about is Meaningful Names for Classes and IDs. Too often I see IDs and classes with unsemantic names and that makes no sense. To this I would like to add the very common overuse of classes. Often I see people putting classes to almost every element they want to change. They completely misses the idea of Cascading Style Sheets. As the name implies, elements inherit the rules down the structure.

    Just a few thoughts from me :)

  5. says

    Never really thought about ordering my code alphabetically, interesting appoach though.

    What i tend to do at the momemt is organise my code into blocks, for example i have a block of code for everything in my HEADER, another block of code for everything in my FOOTER etc, and by using comments i find what i need very easily.

  6. says

    Hi

    I find the statement misleading…

    “One of the most irritating things to see is multiple rules written out on a single line as if the person who coded it was running out of lines and crammed everything onto several.”

    I enjoy writing CSS on single lines and I use indentation to reflect my markup, I also don’t sort my rules alphabetically, it doesn’t mean I write bad or unmaintainable CSS, I find the suggestions you are making actually make me less productive.

    I write single line unless I see a logical break in a line that I will force so that my CSS is still legible without having to do horizontal scroll. I know there are arguments for doing multi line rules for versioning etc however it does still work without all the extra lines.

    This article is bias to one style of coding CSS, it’s not the only one and not everyone will testify to it being the best.

    As an aside, you don’t go into the fact that when you use multiple stylesheets you are introducing http requests that will in fact hinder your load times, you go into things like alphabetically sorting selectors when in fact they mean jack when you add a bunch of CSS files with concatenating them on the server.

    Sorry if I seem quite negative, this article seems a little like sloppy OCD, I do agree with some of your points as they are common sense however you have definitely left stuff out of a “comprehensive” CSS article and bashed my favourite coding style in the process.

    Perhaps you could have gone into good ways of sharing the cascade for optimal stylesheets. I don’t know if you are familiar with stuff like Object Orientated CSS (http://oocss.org/) which is a great way of optimising CSS and believe begin to show a deeper knowledge of browser rendering and the cascade.

    Anyways, it’s always good to see folk covering the basics as it is valuable knowledge, just don’t mar it with personal preference.

    Cheers

  7. says

    alphabetical order? really?

    I’ve never heard of that.. seems silly to be honest

    otherwise pretty consistent with what I do :)

  8. Matthew says

    These are some usefull tips, especially on the removal of unused styles – I always clutter up my stylesheets at some point. However, I don’t fully agree on the Alphabetical Order you suggest for stylesheets.

    Instead, I suggest grouping your styles in a more meaningfull way. For example, I have separate parts for general styling (fonts/regular markup for content etc) and specific parts of the website (such as ‘footer’, ‘listmenu’, ‘table with data’, ‘form for data’, ‘general structure’ etc). This greatly helps when modifying a certain part of your site (which is much more likely then editing all parts starting with the same alphabetical letter)
    If you fear not being able to quickly find stuff in this file, you could add an index in comments or just use your searchkeybind. I usually make an index like this and start each section with a similar code for searching.

    /*** INDEX
    *** 001 – general div structure
    *** 002 – general markup
    *** 003 – listmenu
    ….

  9. says

    When i write css, i like to use one line to all style for one elemnt and use indent and new line to separate “section” of css.

    Something like this:

    /* box comment */
    .comment {…….}
    .comment h3 {……}
    .comment_content {……}
    .comment_autor {…..}

    /* footer */
    #footer {…..}
    #footer ul {……}

    etc ;)

  10. says

    Good post. I find if you have a huge CSS file – I’ve just been working on one with 5000 lines! – you can identify the line number you want with Firebug or Chrome Developer Tools and then jump straight to that line in DreamWeaver – Ctrl-G (PC) Cmd-, (Mac).

  11. says

    Alphabetical order – is this really quicker to use while editing a document? Wouldn’t it be more efficient to group selectors based on the document hierarchy – all of the header selectors together, navigation selectors, main content selectors, etc.? If I’m changing the styles for the footer, I won’t want to jump around different sections of the document to find selectors in alpha order.

    “One of the most irritating things to see is multiple rules written out on a single line as if the person who coded it was running out of lines and crammed everything onto several.” For me, if a selector only has a handful of styles, they always go on the same line. It’s much easier to type, and not at all difficult to edit later. If a selector has quite a few rules that look jumbled or confusing to navigate (especially if they have a long background rule or something similar), I do break it up into multiple lines for ease of editing. I don’t think we should characterize coders who are efficient in writing on multiple lines as “irritating” or that they did it because they felt they were running out of lines.

    “For example, if you create a class that is styling a footer widget bar, do not name the class widget bar if you have others, but rather footer widget bar as it describes it exactly and when you get back to it at a later date, you will know what it is referencing exactly.” This is, unfortunately, less semantic. A widget bar is a widget bar is a widget bar. If you need to target different widget bars, combine selectors (#footer .widget-bar). This is a great article on this aspect of semantics: http://www.smashingmagazine.com/2010/07/14/when-one-word-is-more-meaningful-than-a-thousand/

  12. says

    You know, I never thought of alphabetizing my CSS. Great tips that every developer/designer should at least be aware of, if not follow.

  13. says

    Great article, and I agree with it all except ‘One Line per Rule’. I use a one line per element approach, I find it far quicker to find what I am looking for, and it stops the file being unnecessarily long. – I guess its a matter of personal preference though.

    Definitely agree with the last point!!!!

  14. BT says

    Unless I’m missing something, since browsers render CSS based on LIFO (last in, first out), it doesn’t make sense to alphabetically order one’s CSS. Sure it would make it easier to locate classes when editing, but it would compete with inheritance and giving classes meaningful names.

  15. says

    Sorry I can’t stand one liners either! It might be more efficient and help with load time since the code is more compressed, but everything running together is a no go for me, I can never find what I am looking for. So annoying! Maybe its a designer VS true coder thing, I don’t know. I need my white space even in code ;)

    As far as keeping everything is an alphabetical order, that would be to hard to do and I don’t think it would make sense. I keep everything in sections from top to bottom. All global classes, then nav, header div’s, content, then footer etc.

  16. David says

    By all means, don’t order CSS alphabetically. Remember, it’s about CASCADING and INHERITANCE. So order it in a way the elements you want to inherit styles from other elements are noted after them. General styles first. Exceptions last.

  17. says

    Structure wise, there is no right or wrong. Minify it, and it doesn’t matter how much white space you have, or indents, or whatever. I write in block form, minify puts in a nice pile of one line mess.

    Also, Andrew (above) posted what that new HTML5 boilerplate template is using for browser hacks. Way easier than using seperate stylesheets.

  18. says

    I`m with Jeremy on this one, at the and of the day you want to improve the site speed so it is important to minify, gzip …
    I personally have the nice and clean css, with comments and so on, stored local and the short mess is one the server. However, to keep the workflow clean and organized the tips in this article are great. (not sure about the Alphabetical order)

  19. Jorgen Kesseler says

    Great tips, although I disagree on the comments. Comments should be used wisely and sparingly. It’s my experience that a boatload of comments actually reduces the readability of your CSS (and all other code for that matter) instead of increasing it. Whenever you want to write a comment you should ask yourself why your code needs a comment to explain it. Try to simplify your code before adding comments.

    Also I don’t like one-liners, try to keep your lines no longer that around 70 – 85 chars apparently this is cognitive limitation that printing and publishing typographers figured out a long time ago. See http://paul-m-jones.com/archives/276 for more on that.

  20. Amos Vryhof says

    Some of these tips are good….others are pretty bad.

    Alphabetize CSS? No. — Why? Inhereitance, Semantics.
    Separate files for CSS? No. — Why? It creates more server requests.

    Aside from that, the other tips aren’t bad. Some people might disagree with the one line per rule thing, but I do. It’s mostly because it has been my coding style for many years. I use this method, then run it through a CSS Compressor before deploying.

  21. says

    Hey there,

    “Split Into Multiple Files” – in some ways a pretty good idea for finding code-snippets, but what about the amount of HTTP-Requests? With an closer look to the speed of a webpage you have to reduce the number of http-requests.
    Maybe you should give a suggestion to combine them for production-state.
    there are a lot of ways to combine, compress and gzip them for perfect output.

  22. Jim says

    I also must disagree about the one line rule. If you are writing the code for someone else or the CSS will eventually be passed to another coder – then sure, multiple lines in the standard. However, if you are going to be the sole styler for a project and you prefer one line, then all the power to you!

    I write CSS on one line, but I also have an organized system to it. Box model properties, background properties, text properties, other (in that order). So I know if I need to adjust the padding that it will be toward the left.

  23. says

    Sorting Alphabetically is an interesting approach, but I honestly don’t see how that is more comprehensive???

    I prefer to sort everything starting with the defaults for the major layout of all pages, and then by specific view pages… within each “view type” section I then sort in the order it appears in the document. I also use one stylesheet as my “master” and then different stylesheets for things like “fonts” or “forms” to keep everything organized.

    When I’m done building I then compress all of my css into a minimized file, but keep comments just so identify the different style sections. I also keep backups of all of my original stylesheets. It’s still easy to edit compressed files, I just use CTRL F to find the selector I’m looking for.

    For example, I would start my master stylesheet with:

    /*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
    /* ALL PAGES LAYOUT */
    /*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/

    *{ /**reset all**/

    }

    /*clearfix – easy-clearing for floats*/

    }

    body{

    }

    #master-wrapper{

    }

    /*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
    /* HOMEPAGE SPECIFIC */
    /*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
    #home_pgs #topphoto-left{

    }

    and so on…

  24. says

    Good article, not sure about putting styles in alphabetical order though- I prefer to group by hierarchy – global, structure, text etc.

  25. says

    I have mixed feelings on a lot of this. I understand the importance of some sort of order to the chaos of coding… or in this case writing rules. Something I have started using recently is the ruby gem LESS CSS. I use it to compile my css before sending to the server. You can write your styles how you want, comment to your hearts content, separate selectors into different sheets, etc, etc. Plus LESS CSS allows for some other really great features, nested rules, vars, & mixins. The compiled file writes one rule per line, removes comments, and also groups selectors with the same attributes. Can take it a step further and compress the CSS before sending to your production server. Your dev code looks different then production, but production is for browsers, not humans.

    As for organizing rules in alphabetical order… who does this? Seems like an unnecessary step, plus we always have “Find” if we know the selector name. I agree with many of the suggestions above me, I groups my rules by location, header, content, footer, etc.

    Any way my 2 cents… great post… always good to get us thinking and introducing ideas.

  26. says

    Thanx for this article. Allthough I allready practise most of the given tipps there is one point on which I don’t agree with: Seperate CSS into different files. During developement, that is definitivly a great thing to keep everything clear for you as the developer. But when it comes to publishing I believe it is best to join all CSS-Files into on and compress it so the website doesn’t need to make several requests which will definitivly result in a slower performance of loading. Especially today, where Google and other searchengines reward fast loading websites with better rankings.

  27. says

    Can’t agree with one line per rule. I find the class/id a lot more faster then with the “one line per rule”, and i also find the rule much faster, 1/10th of a second of scanning the line and i already found it.

    But maybe for beginners the “one line per rule” is better, i used it when i was starting with CSS, but didn’t tried them in single line so not sure if it’s better or not.

    There are few “no no” when it comes to organization, but the “rules in single line” is not one of them.

  28. says

    I agree with most all of these points, but alpha css? That’s just crazy!
    Comment it intelligently, group appropriately and that should be sufficient…

    I would like to see an app that would organize, group, sort, alpha, shorthand… css—well.
    Anyone have a recommendation?

  29. says

    I really like splitting my CSS up into multiple files.

    By using SASS [http://sass-lang.com/] (which is awesome BTW) I can have the benefit of having multiple files for ease of development and a single compiled CSS file for speedy downloading in production. And making sure gzip is enabled on your server helps too.

Trackbacks

  1. 10 Great Tips for Writing Better And More Comprehensive CSS…

    There are many different coding styles but the main train of thought is that we’re all after one common thing: organization and better code….

Leave a Reply

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

* Copy This Password *

* Type Or Paste Password Here *