Chip, Eddie, Keith, Reva, Matt, Dan, Jon, Michelle, Scott, Amanda, Bruce, Mary, Kent, Brian, Robert, Chris. Chad, who holds court at the Oregon branch office not pictured.

It turns out that Flickr does the same sort of thing. Their solution: flags and flippers. Interesting read.

Converting a Photoshop pitch to a static HTML/CSS layout is a fundamental part of client-oriented web development. It can be hard work, not least because it is difficult to simultaneously focus on the appearance of the site and its structural foundations.

The usual solution to this is to muddle through and keep tweaking a steadily expanding morass of CSS until the site resembles the original .psd. This way of working is unstructured, which makes it stressful and self-limiting.

Let’s look at a better way.

Separating structure and appearance

A more disciplined way of working involves separating the structure and appearance of the CSS into two separate files, like this:

    <link rel='stylesheet' href='styles/structure.css' type='text/css' />
    <link rel='stylesheet' href='styles/appearance.css' type='text/css' />

But aren’t appearance and structure separate already in CSS?

At this point you may be thinking that CSS is already predicated on the idea that structure and content should be separate. HTML for structure and CSS for appearance, right?

This is true if “appearance” includes attributes such as float or position.

We want to really separate the the attributes responsible for layout – position, float, padding, margin, width, height, border, etc – from those responsible for decoration – background, color, font-*, text-*, etc.

We also want to be able to visualize the structure of the CSS. This means adding false background colors to elements in structure.css so we can see what effects those elements have on the layout. The predefined CSS colors such as “green” or “red” are great for this.

How structure.css and appearance.css see a page element

Structure.css might describe a page element like this:

div.feature_content
{
    background: green;
    padding: 5px 20px 15px 20px;
}

while appearance.css is concerned with this:

div.feature_content
{
    color: #00326a;
    background: #e8e8e8 url(images/feature_foot.png) no-repeat left bottom;
}

This means we can easily switch off the appearance file and look at a purely structural layout. If, for example, we need to add an element and inadvertently break a float clearance, we can metaphorically lift the hood on the layout and immediately see what is wrong. It’s like having X-ray vision for HTML.

With both stylesheets switched on.

With just structure.css switched on.

Visualizing in action

If you watch the animation at the start of this post again, pay close attention to the position of the top navbar.

When I first started blocking out the page the navbar was inside the top (‘header’) block. Later I realized it would be easier to position if it were the first element in the second (‘content’) block.

So I switched off appearance.css (by breaking the tag with an underscore,) and moved the nav bar’s div. The structure was fine, so I deleted that underscore and the hood went down.

The important part of this is that I was immediately confident that the change had no unexpected impact on other elements in the layout. I knew the layout of the page, even when it was in flux, because I could see it.

Divide and conquer

The important thing is that visualizing CSS isn’t a tedious “best practices” kind of thing. It really does remove a lot of stress and confusion from development. Give it a try; once you start dividing your CSS this way you’ll wonder how you managed before.

• More about CMM
• The job posting

1. App-specific workarounds: sometimes feasible, sometimes not
2. Local modifications: wherein we dork around with the library code on our end, fix the bugs, and then maintain our own separate branch of the library. These made merging in new changes from upstream fun (in that why was I programmed to feel pain kind of way).
3. Find/Write a replacement: You’d be shocked at how often we didn’t do this. Or, alternatively, underestimated how difficult a particular issue is.

In the last few weeks alone, GitHub’s changed that. Now, the libraries I want are on GitHub as rubygems or PHP tarballs or what have you. And when we encounter issues, the process is smooth:

1. Fork project. GitHub has a button for this.
2. Get our fork, make local changes, commit and push up to GitHub.
3. Send a “pull request” to the original author to let them know we have patches that they may want. GitHub has a button for this.

My contributions are available for whoever wants them.

Now, if the original project checks in a few bugfixes I want, I can cleanly merge them in and keep my local fixes. And if upstream wants my fixes for the “canonical” repository for a project, then they’re welcome to them whenever they like. Git makes the magic happen, and GitHub makes the magic ridiculously easy.

How the hell did we develop software before this?