Amber Weinberg: Freelance Web Developer specializing in semantic WordPress, Mobile, CSS and HTML5 Development

The Blog

Making Your Code As Beautiful As The Design Itself

Posted on 03/02/10 in blog, business about , , , ,

A website’s design gets all the glory. When someone visits a site, you’ll hear them talk about how awesome the design is–but, do you ever hear someone talk about how awesome the code is? Never!

Regular people can’t see code, nor do they care to see it or what it looks like. It’s precisely this reason that there’s so much ugly code in the web world today. People don’t see it so developers don’t believe that clean code is important, but it is.

It’s quite rare to find a clean coded site, even from huge companies who should have the budget to pay for a good developer. However, it’s just as important to have beautiful code as it is to have a beautiful design.

Why Should It Matter?

Most of the time, messy code works just as well as clean code. So why should it matter if it’s pretty or not?

  • Quicker to update–Organized code is easy to navigate and update. Save yourself some time in the future by making stuff easier to find now.
  • Faster loads–Often, clean coding uses less code, which means it’s faster to load.
  • Professionally–Would you rather pay someone who gives you a junk heap of code you can’t read, or someone who hands you correctly nested and organized code? Which one would make your life easier? Which one shows more professionalism?
  • Find errors–With organized code, there’s less of a chance you forgot to close a tag or that you closed them in the wrong order. Plus, if you do make a mistake, it’s a lot quicker to find it.

Beautify Your CSS

There are several ways that I’ll show you how to organize your CSS. Of course, beauty is in the eye of the beholder, so you may not find that what works for me, works for you. Experiment with a few different ways you can organize your code to find what works for you.

  • All in one line–Placing the entire rule on one line shortens the document, making it a smaller file size, easier to read and quicker to locate what you need. For example, instead of:
    div {
    background: #FFF;
    font-style: italic;
    font-size: 18px;
    margin: 20px;
    padding: 10px;
    font-weight: bold;

    Try doing this instead:

    div { background: #FFF; font-style: italic; font-size: 18px; margin: 20px; }
  • Group like elements–I like to group similar rules together so that I can find everything I’m looking for in one section. For example:
    div.element {}
    div.element a {}
    div.element ul {}
    div.element .class p {}
    div.other {}
    div.other a {}
    div.other p.class {}
  • Sectioning–It’s also good to section off your CSS by the area of the website where it is located. I use comments to call attention to the sections and usually section them off by header, nav, footer, main page and subpages.
  • Semantics–Semantics are all about giving your items proper names. Name your classes and IDs with pertinent names, such as “header”, “nav”, or “bkg.jpg”. This allows anyone who needs to make updates to the site to find what they’re looking for quickly.
  • Shorthand–Shorten your background, font, padding, margin and border properties by using shorthands. Instead of using a single property for each, combine them into one. Instead of:
    div { padding-left: 20px; padding-right: 30px;  padding-top: 50px; padding-bottom: 10px; }

    do this:

    div { padding: 50px 30px 10px 20px; }
  • One CSS organization “tip” I personally hate is tabbing your rules into a hierarchy. In my opinion, this wastes space and makes it harder to read, but you can try that out and see if it works for you.

    Organizing Your HTML

    Organizing HTML is pretty quick and easy. Here are a few tips.

    • Tabbing–It’s important to properly tab your HTML code, otherwise it becomes almost impossible to read or find that one missing closed div. Convention says to tab once for each nested div, or div inside of a div.
    • Space sparing–It’s good to put some blank lines in between sections of your code, but too many can be counterproductive. I tend to space out separate main divs.
    • Semantics–Like your CSS class and ID names, everything should be named properly, including images and video. This can save you loads of time in the future. Your main background image should be name bkg.jpg (or something similar), not image2345.jpg.

    Do I Hafta??

    Of course, you don’t have to organize your code or make it look good. After all, no one is really going to look at it, right?

    Wrong. If you’re planning on coding for a living, lots of people are going to look at your code. In fact, you may be losing business without even knowing it! A lot of potential clients will pass on a coder if their portfolio and own site are filled with nasty code.

    Share Your Tips!

    What are some of your tips for great looking code?

    My post was originally published on FreelanceFolder.

    Amber Weinberg specializes in clean and semantic HTML5, CSS3, responsive and WordPress development. She has over 15 years of coding experience and is super cool to work with. Amber is available for freelance work, so why not hire her for your next project?

    Like this post? Please share it on Twitter or Facebook.

    • When I’m coding I don’t do it all in one line, I change it when I am done with coding, my editor PSpad has got this functions 🙂

    • I have actually used another route for CSS before and tab it identical to my HTML which makes it even easier to find sometimes 🙂 depending on the scale of the site.


    • No matter how good you are, you can only type so many keystrokes in an hour. “Keep it pretty” tips like these not only help beautify your code; they also save keystrokes, saving you time in the end. And yes, those milliseconds add up. Fast.

      I notice you use this technique by example, but don’t point it out as another tip:

      – If you’re using any of the 256 web-friendly hex colors, you can write those in shorthand as well. In that case, each of the RGB pairs are identical numbers, so just use one from each (#RGB) instead of both (#RRGGBB) EX: #336699 shortens to #369, #FFFFFF shortens to #FFF, etc…

    • I personally don’t prefer to place my CSS on one line…easier for me to scan that way and I don’t lose anything by it.

    • Very interesting. Thanks for the tips! 🙂

    • I agree with the other commenters about not putting CSS on one line. Sure it makes the whole document easier to read but it makes reading the individual styles a lot harder, which is counter productive since you are usually editing individual styles. I code like this:
      margin: 5px;
      padding: 5px;

      background: #fff url(img.img) no-repeat top middle;

      I also section everything into how it is sectioned in the HTML, so a section for the header, nav, main content, sidebars, footer, etc.

      The reason I code this way is so I change the individual styles quickly. If I need to get to a particular section or style quickly, I can just my editors quick find to jump to the idea since I already know what it is. Its CSS so you should know what element you are going to be styling. Its not like PHP where you have to scan the order of things to follow the logic.

    • Halen

      /* Comment */
      I second the sectioning CSS based on the layout of the HTML. Also, commenting your code in sections helps a lot when zooming around on your scroll wheel. I do prefer one-lining – as it makes the file length smaller, and much less scrolling to do.

    • I definitely agree that you should organize your code for CSS, HTML mark up and, I would add, Javascripts. This helps you later down the line to effectively troubleshoot any problems that may arise.

      I break my CSS into commented chapters with headings so I know what relates to what. What I never got the hang of is writing all of the code on one line. It is just too difficult for me to read.

      I also, which is definitely a personality quirk on my part, will alphabetize the rules. It makes it easier for me to go back and check if I’ve missed anything or need to remove anything. It’s not something I would recommend to all, but it works for me.

      Lastly, I will combine all shared rules as much as possible to reduce the amount of code written. For example, I will have a section named Positioning and place all of the shared positioning rules together.

    • That would be interesting to see, I’ve never heard of anyone doing that before.

    • Right, there were a couple of other techniques I thought about after the post was written, it’s hard to remember everything 😛

    • I think it depends on the person. When I get a site that was coded by someone else with multi-line CSS, it drives me crazy and takes me forever to find stuff I’m looking for.

    • The way I do my rules is this:

      .class { position/floats, margins, padding, text or styles, background }

    • Nice article Amber. I definitely agree about keeping your code clean and neat.

      I work for a large company with over 7 massive e-commerce sites, and currently, we are creating all the sites again from scratch. Why? Simply because the markup and the CSS has just gotten too bloated. Unneeded and duplicate classes, divitis, and the whole shebang. Our goal: to keep the new site’s markup as clean as possible. Every front-end developer needs to read this article and apply these methods.

      BTW, single line CSS all the way! 🙂

    • This is definitely something that I am working on improving. Not that I’m totally disorganized in my coding, but there is always room for improvement. Especially when you are basically self-taught.

      I tend to group my CSS according to the HTML layout as well, header, main content, footer, etc. I use a single line for CSS elements if there are not more than about 3 attributes. After that I find it harder to scan through the attributes that are there. But maybe that’s the smaller screen and windows that I am used to working on.

      Definitely some good ideas here and always nice to read through comments from others who contribute. Thanks, guys.

    • I agree, I avoid single-line coding because it slows me down a lot when I’m trying to edit code, which is what I find myself doing far more often than writing entirely new code.

    • Vassilis Mastorostergios

      “All in one line–Placing the entire rule on one line shortens the document, making it a smaller file size, easier to read and quicker to locate what you need.”

      Maybe it looks better and loads faster but by no means does it make it easier to read and locate what you need.

      Most of the time you don’t search for the selectors, but the actual attributes that you’ve changed for them.

      There’s CTRL+F for finding selectors in a 1000 line CSS file 🙂

    • Halen

      I’m sure the one-line debate could rage all day, but it’s all going to come down to personal preference anyway. That being said, personally I find dealing with condensed document does improve it’s navigation, and it’s readability. It’s not like my attributes are so jumbled up that I can’t easily find what I’m looking for. I can guarantee you they are to the right of where I’m looking. Or maybe I take my 24″ monitor for granted, who knows. 🙂

    • I might suggest using SASS ( or LESS ( Some may argue this adds an unnecessary layer to your workflow – and for really small projects, that may be true, but as anyone who has authored long stylesheets, it’s priceless.

      Either will compile SASS/LESS code into CSS (and you can customize how it’ll compile).

      The syntax for either is very nice, LESS is more true to CSS syntax, but SASS is essentially HAML: will be familiar to any other Ruby developers out there.

      They both offer the things I really wish CSS offered in-built (but at the same time, am glad it doesn’t): variables, mixins, color arithmetic and, most importantly, selector grouping.

      Check out the sites, there are code samples on the front pages.

    • I prefer coding well, then using online tools to pretty it up even more.

      Here is an css formatter:

      Here is an HTML formatter:

      What do you think of this? I’ve never had issues after using them.

    • It’s really interesting to see how differently we all do for the same thing 😉 Keep the comments coming, even if you disagree, it’s interesting!

    • Pingback: links for 2010-03-03 « random thoughts and casual ruminations()

    • brett

      nice post.

      When coding CSS i usually prefer the way:
      multiple properties;

      its easier for me to scan code vertically rather than horizontally….if its a single property i do it in one line and if its multiple, i use above notation.

      i think as far as usability is concerned top to bottom is more easy to scan rather than left to right….u can see the properties in a…z order sort of sorted…horizontally its very difficult if there are huge nos of properties in one class….

    • George Carter

      Great post.

      I’m trying to break into the web design/development area and am preparing a portfolio of sites I’ve put together. I’m sure potential empolyers/clients will “peak behind the curtain” to get a feeling of my coding style. A post like this helps me project a sense of professionalism.


    • In my opinion “all in one line” is much better to just find some element you’re looking for.

      But that’s it. It’s definitely not easier to edit CSS attributes within that perticular element if you put it all in one line.

      I always code like:

      div {
      background: #FFF;
      font-style: italic;
      font-size: 18px;
      margin: 20px;
      padding: 10px;
      font-weight: bold;

      Nice post by the way :).


      Kinda like this?

      It makes it easier to browse, and I just do everything in order.

    • Anton

      I agree, the first thing I do before editing this sort of code is break it onto multiple lines.

      Most coding style guides have a maximum length suggestion, usually 80 characters, this is for a very good reason – it saves scrolling in 2 directions, and unnecessary line-wraps

      Multi-line CSS allows you to quickly comment out troublesome patterns.

      If you want a way to navigate, any decent editor will have a style-list that you can use to quick-jump.

      The space-saving is a red-herring too, even if it mattered, a newline character is the same size as a space.

    • Nepathean

      Tnx Amber! I will definitely switch to “all in one line” style , after reading this great article.

      Tnx again! Muchos besos!

    • I’m surprised no one has mentioned one of my most-used ways to traverse a CSS file.

      Firefox > right-click > inspect element > check the line number in Firebug. 😀

    • exactly ^_^

    • I agree here. I think one-line format is good for keeping your file small. However, is it worth the headache of having to read what could end up being a very long line of css for a particular element.

      Im less about writing it for me, and more about writing it as if I might give it to someone else for showing an example of something or to exchange info. The easier it is to read it, the more helpful it will be.

    • I mostly use one-line CSS. But when there are a lot of declarations, I will do a hybrid of sorts.

      I’ll put the ‘static’ stuff like image url, etc., onto the first line, then put the more ‘dynamic’ stuff on a second line or individual lines. This would include possibly color, definitely positioning/padding/border, and anything else I’d need to modify during the final phase of tweaking.

    • Pingback: The Best Development Articles Of :: Freelance XHTML, CSS and WordPress Developer Amber Weinberg :: Nashville, TN()

    • I personally can’t stand single line. What if I’m viewing the CSS in firebug and I need to update a property….property is on line X….but so is about 10 other properties.

      I prefer to use multi-line with the following rules:
      1. CSS rule can be single line if it has only 1 property.
      2. All properties are in alphabetical order.
      2a. If position is defined, I will tab out the top/right/bottom/left (in that order).
      3. I have a giant comment block at the top to keep track of z-index, when added to elements.
      4. I also use LESS….and it’s awesome!
      5. I minify my CSS in production, so saving whitespace isn’t an issue.

    • Interesting technique (tabbing your css, the same you do with html). I did that for a while, but switched back to non-tabbed lines, due to its unorthodoxy and working with other devs. Still kind of like it, though.

    • I would emphasize the file size part, too, especially when dealing with large stylesheets. After all, a compressed stylesheet is stripped of ALL white-space, so placing rules on one line definitely helps. But then, the author’s preference with one coding style or the other, is where it really counts in ease of use.

    • Pingback: Evolution of the web, VIM cheat sheet, KendoUI, Where is the fold?, Beautiful Code, Ugly JS | Serene Global()