CSS Coding Style and the Unbearable Tendency for People to Adore Whitespace in their Source Code

CSS coding style doesn’t get a lot of play. Most people are happy to stick with the convention of one property per line, like this:

  1. #score {
  2.   background: yellow;
  3.   width: 12em;
  4.   border: 1px solid orange
  5.   padding: 2em;
  6.   margin: 3em 0;
  7.   display: none;
  8. }

I, for one, can’t stand that style. I’m heavily biased towards information-dense coding styles, which don’t have much whitespace. People mechanically argue “oh but whitespace is so important etc” as if we were designing a modern art installation. Well, whitespace is indeed essential, but you have to discriminate between a touch of elegant whitespacing for the sake of clarity, and “oh dear! My 80-column row seems to have just 12 characters on it. Come to think of it, every row on my 30-inch Cinema Display has 12 characters on it.” Seriously, I don’t know why anyone would use an 80-column terminal anymore, unless they enjoy coding on their iPhone. I tend to think 120 or 160 is ideal; any more than that and most people won’t be able to see the whole thing without moving their head. Anyway, I’ll be conservative and assume 80 columns. The average end column in the above code snippet is roughly 15, which means in your scrawny 1975 80-column terminal, you’re filling 20% of it with information and 80% with whitespace.

There’s an old figure that says the average programmer codes 10 lines per day. It’s obviously not a very accurate figure and maybe it was meant to include all the non-programmers on the project or something, but the point is interesting, as there’s probably some reasonably consistent LOC per developer figure (obligatory mutatis mutandis caveat). Seizing on this historical figure, Bruce Eckel said a while ago (paraphrasing) “if I only get 10 lines a day, I want them to be good ones”.

That’s why I favour information-dense coding styles. As a programmer, you’re supposed to be an expert user who spends all day in front of the same system. This is a typical example of a situation which demands a “Sovereign Posture”. It’s an expert system. When people long for glorious pastures of whitespace, they’re ignoring the fact that with sufficient practice, they’ll be virtually as proficient at reading and writing a more information-dense style, and vastly more efficient by having so much more code available at any time. It’s the same reason why Real Programmers commit to learning Unix and Vi or Emacs; if you’re going to spend decades working in this environment, why wouldn’t you spend a few days committing to the most efficient tools available?

For the record, I still have plenty of whitespace in my programs, but when there is a decision to be made between one popular convention and another, I almost always go for the one which reduces whitespace. I have enough faith in programmers’ pattern-detection skills to know that in time, they will be fine with either style, but the one with less whitespace will always give them more bang for their Cinema Display buck.

Back to CSS. Here’s how I’d format the above snippet:

  1. #score { background: yellow;  border: 1px solid orange;
  2.              width: 12em;  padding: 2em;  margin: 3em 0;
  3.              display: none;
  4. }

What I do is group similar attributes on each line. I’m pragmatic about the precise rules. If it’s just a handful of properties, I’ll stick them all on the same line. If there’s more than that, then typically I’ll have one line for appearance (colour, fonts, etc.), another for layout, and possibly more for other things like display settings or detailed positioning. You also don’t need whitespace between each rule either, so you can often end up with a whole sequence of related one-liner rules:

  1. /******************************************************************************
  2.    SCOREBOARD
  3.  *****************************************************************************/
  4. #scoreboard { background: black; color: white; }
  5. #homeTeam, #awayTeam { color: pink; text-align: right; position: absolute; }
  6. #homeTeam { top:20px; left: 120px; font-size: 8em; }
  7. #awayTeam { top:80px; right: 120px; font-size: 5em; }
  8. ...
  9.  
  10. /******************************************************************************
  11.    ARENA
  12.  *****************************************************************************/
  13. .player { color: #f99; }
  14. .runner { color: #99a; }
  15. ...

This format is not only denser but also easier to comprehend as related properties are grouped together. The typical one-line-per-property format tends to include a random jumble of properties; rarely does any thought go to the order in which the properties appear.

Another thing that helps with CSS brevity is learning shorthand formats. Use “border: 1px solid orange” instead of “border-width: 1px; border-style: solid; border-color: orange”. Use “margin: 3em 0;” instead of “margin-left: 3em; margin-right: 3em;”, and so on.

The Problem with Bug Reports

Ivan on writing bug reports:

Mostly, you get no feedback. Sometimes people log bugs, but not very often. With open source software, or web sites providing some service, if it doesn’t work straight away (and very simply), mostly people will ignore it and try the next thing that looks like it might do what they want.

On the whole, bug reporting in open source projects is borken. Why?

  • You often need to sign up for an account in order to log a bug. They should have used Captcha instead if worried about spam.
  • For larger projects, people are discouraged to post if a bug is already there. Or if they’re not discouraged, there are loads of duplicates which no-one can deal with. Totally understandable, but it means a lot of people won’t bother at all. The solution is some kind of AI style pattern recognition, as in “Is your bug one of these?”. Which would be great if systems like that actually worked; most of the time they’re just frustrating impedances.
  • Bug reporting isn’t encouraged by the software. At the least, any error dialog should be linked to a troubleshooting and feedback portal. Better would be to link to a commentable page about that specific error type. “Error code 48278″ is so ’70s. Get with the ’90s guys and make it “/errors/48278″.
  • It takes too long to explain how to replicate. Part of the reason is that URLs aren’t used where they could be. I’ll explain more about desktop URLs later.

The Little Bug that Could: Firebug Book Chapter

<gush> Firebug is awesome. Joe Hewitt is a legend.

As I’ve said before, Firebug is among the most usable software tools ever developed. I don’t just mean compared to other software development tools. I mean against all user-facing software. It’s single-handedly improved my Ajax productivity by at least 100% (that’s my estimate when making changes to larger Ajax code bases). It’s made Ajax development much easier to get into for newbies and a much more pleasurable place to be for all developers. </gush>

So I’m pleased to announce I’m writing a chapter about the bug in the upcoming Sitepoint text, The Art & Science of JavaScript”. To be published by Sitepoint and with coauthors Simon Willison, Christian Heilmann, Ara Pehlivanian, Dan Webb, Cameron Adams, James Edwards, and others. I can’t talk about timelines, but you’ll notice the Amazon entry above is stating January ’08.

Would you like to review the chapter? Drop me a line – [email protected]

As well as explaining the various parts, I’ll be sharing tips on when to use different features and how to get the most value out of them. Here’s an outline:

* Meet the Bug
  What is Firebug, when to use it, overview of functionality, how it has
    impacted modern web development.·
  What's missing at time of writing (other browsers, cookies)

  • Installing Firebug

    Downloading and installing the plugin, opening it up and enabling it for certain sites. Windowed vs docked mode

  • Firebug Anatomy and Idioms

    Overview of sections in the Firebug window

    Idioms - point out that most things are cross-linked, searchable, and editable. Options menu.

  • The Console

    Introduces a sample application used throughout the chapter, then introduces the console (logging, errors, running JS commands).

  • Viewing and Editing Your App on the Fly

    • HTML
    • Including Layout and Style
    • Mention Inspect option in popup menus.
    • CSS
    • Javascript
    • DOM
  • Debugging Your App

    • Breakpoints and tracing
    • Watches
    • Stack trace in the console
  • Performance Tuning Your App

    • "Net" tab
    • Profile button
    • YSlow
    • Reference Related Tools below
  • Related Tools

    • Firebug Lite

    • YSlow

    • Microsoft Script Debugger

    • Other Firefox Extensions

    Brief list of a few other useful/alternative extensions, e.g. Web Developer Toolbar, Measure-It, Stylish