Here is the final build and its code is on GitHub.

HTML first

I built this HTML-first. No CSS other than the UA’s whatsoever. No images, no styles, no JS, no classes, no containers, nothing. I started with pure text-level and content semantics. No divs, no spans, nothing that would in any way aid styling. Nail your pure, raw HTML first before even thinking about CSS. This ensures you’re thinking fully about the most important aspect of any site; its content.

No IDs

The build uses no IDs for styling. This was quite an odd shift for me to make, and I made it a number of weeks back. The main drawback of using IDs is that they introduce a specificity wild card not unlike using !important (though obviously not as horrible). By not using them it means that I can’t really get tripped up by overly specific selectors as easily as I could if I was using IDs. I’ve not removed the chance completely, but really easily and quickly lessened it.

‘Ugly’ classes to do lots of heavy lifting

There are quite a few classes that some might deem ugly; the media and grid classes instantly spring to mind. The thing here is that classes aren’t semantic or insemantic, they’re merely sensible or insensible. If a div is 6 columns wide then a class of .grid-6 is totally sensible, if it needs to change then change it. If you ever redesign you’ll be touching the markup anyway; I’m convinced the pure CSS redesign (in a commercial world) is a myth.

These classes also bring performance benefits, once a class gets called once it becomes free to use again; a performance freebie. If you use grid-6 once on a page, every subsequent usage is totally free, from a performance point of view.

Portable sprite icons

The .s class is a theoretically horrible class, but as we outlined above, nothing (except micro-formats and similar) reads or even cares what you name your classes. You can name a class anything you wish and a browser has to honour it, just pick wisely!

So, the .s class is one good example. Whenever you want to use an icon background image you ideally want to sprite it, but in fluid elements this isn’t possible. Enter a spriting element.

This is just an empty element that gets the sprite applied to it in its own fixed width/height box.

Chris Coyier uses pseudo elements for this which is great as it’s really clean, but the major drawback for me here is that they’re not very portable. A pseudo element is tied explicitly to an element in the CSS, so you can’t just drop the icon wherever you wish. Using an empty element means you can drop an icon wherever you wish. It’s six-of-one and half-a-dozen of the other; cleanliness versus portability; pick which one you’d rather have.

I can imagine that 75% reading this still think it’s a horrible, but we need to remember that an empty element affects nothing. It’s empty so it has no content, if it has no content then screen readers don’t encounter anything in it.

You’re probably also thinking that it’s heavily presentational, but there’s really no difference between:

<i class="s star"></i>

And:

<img src=star.png alt="">

The first is just out-and-out better in that it allows you to sprite that image up!

I was asked why an i and not a span. I’m almost ashamed of the answer but it’s purely because i is shorter, it’s as simple as that. I know that a span is probably better suited as it’s devoid of semantics but as there’s no content in the i nothing is affected by semantics anyway. Feel free to use whatever element you prefer though, like I said, my reasoning is kind of shameful!

Mobile first, lay the foundations

I did this build mobile first, sort out the content, the type, the general feel of the site first, then used min-width media queries to build up the desktop version.

Incidentally I don’t use respond.js or similar to get media queries working in IE et al, they get the mobile version. The layout of the site is not that important because a PSD is a clue, not a contract. A PSD tells you how a site should generally appear; the type, the colours, any brand treatments, that kind of stuff.

If you spend enough time on the mobile version that should be good enough to serve as the baseline, anything on top is a bonus for browsers that support media queries.

Grid systems just make life easier

In a similar vein to the above, grid systems are typically frowned upon as being insemantic, but the joy is that, as we covered, classes are neither semantic or in semantic. Plus—even better than that—a div is devoid of any semantics, it’s a generic container element. Adding these to your markup comes free-of-charge. Using a grid system allows developers to quickly construct consistent, robust and efficient layouts in seconds.

‘Extraneous’ divs actually make builds far more robust and extensible

You should never add markup where avoidable, but that doesn’t mean you should avoid it at all costs. Sometimes adding an extra div will make components a lot less brittle, rather than relying on unpredictable style rules and overly slim markup, sometimes it’s just far better to add another div to ensure a more robust build.

Take for example the media object. You could probably build that construct using far less HTML, but then would it be as extensible? You could just assume there will only ever be an img floated left with a p to the right of it, but if you do that and a client asks for a list with that p and a caption under the img you’re in a bit of a pickle; if you just start out with a div on each side to start with then you have the ability to build whatever the client throws at you, and it will always be predictable.

So, add extra markup where it saves you headaches. I’m more impressed by powerful and extensible code than I am with lean and brittle solutions, and I can guarantee which the client will prefer…

Don’t measure stuff

Throughout this build I only measured one thing; the grid system. I honestly think that, in web design, the pixel’s days are numbered. Build everything without a care as to its dimensions. Everything in the build can be moved around and dropped anywhere else without you needing to worry if it’ll fit. All your components should always be fully fluid and only constrained by their parent, in this case the grid system.

Here’s a challenge, next time your designer sends you a PSD designed on, say, the 960GS, resize your browser to 800px wide and build it like that. That’ll really put your fluid, responsive skills to the test!

Be resourceful

During this build I copied and pasted loads of code. I used my vanilla boilerplate, I copied and pasted the media object, the nav abstraction, the carousel. If it already exists somewhere then reuse it! There are no prizes for writing more lines of code; be resourceful.

Take away?

Even on tiny sites, powerful markup is far more quick, robust, extensible and sensible than convoluted, brittle stuff. No one reads your classes except other developers. Users appreciate fast UIs, clients appreciate stable and robust sites and you, the developer, like to save time, be efficient and only solve problems once.

What may at first seem like an ugly class or bloated markup is actually a really quick, predictable and reusable construct.

Websites make us money, so let’s make them as quickly as possible and in the most predictable, future proof way we can.

Finally

There is a video of the build to go with this, but I need your opinions, do you want the full, several hour epic or do you want it sped up to, say, double speed? I’m going to get that processed as soon as possible.

Update

As promised, I recorded the whole thing warts and all. You might be interested to know a few things non-code related about the build-along.

• The whole lot was done on an 11″ MacBook Air with no external mouse or keyboard.
• My good friend Jake, who is wanting to learn a little about web development, was next to me the whole time.
• I cooked and ate my (now famous (in tiny, tiny circles)) chili during the build-along.
• Refreshment was courtesy of Matusalem and Fentimans.
• The songs you saw on my Spotify are not necessarily wholly representative of my taste in music ;)

The normal, non-sped-up recording is now on YouTube. Part 1, Part 2. The sped-up version is proving a little more troublesome; crunching over 4 hours of video on an 11″ Air is taking a while…

Sped-up video

To view the faster video right away, simply opt in to YouTube’s HTML5 Trial, open the YouTube URLs above in Chrome and then select the playback speed options that now appear on the player.

I’ve just about recovered now, and here is the result: Sam Penrose Design—Creative designer and graffiti artist based in Leeds, UK

This was a really cool build for me, Sam was a great ‘client’ in that he instantly ‘got’ progressive enhancement, he was totally cool with the fact that differences between browsers may be quite obvious (and glaring). He was fine with his idea of a design ending up being more like three designs, when different browsers are accounted for.

Buzzword time! This build was:

• Heavily progressively enhanced
• Content-out
• Mobile first
• Responsive
• Designed in browser

I’ll touch on each of these in a little more detail.

Progressive enhancement

Basic really; this site uses loads of gradients, round corners, shadows, all that stuff. None of it works in IEx but that’s cool. Sites don’t have to look the same in every browser (and we took that to a bit of an extreme where media queries are concerned).

It uses my fluid carousel which doesn’t even behave like a carousel in IE, it acts as more of a promo. This is fine, though, as we were careful to only put non-essential content in here. Got a good browser? You get a pure CSS carousel. Got an older one? You get what looks like a nice, fluid promo panel.

In case you’re interested here is a screenshot of IE8:

Content-out

We started off with just the content; I built pure markup to start, with no CSS whatsoever. We got the content into the page and then Sam decided how he’d like to design around that. It worked a treat and kept everything really really clean.

Mobile first

With the content in place, we looked to build the site mobile first. This was really simple, but we spent most of the time on it. We simply created a fluid, single column design. We spent ages working on the mobile, most stripped back version to ensure that it was a perfect base. We wanted to make sure that anything on top of the mobile version would be taking the site up to 11.

Investing so much time on the mobile version was really fun and really sensible, it made the next bit a breeze.

Responsive

Naturally, the site is responsive. The interesting thing is, though, that we’ve not bothered getting media queries to work in IE. The beauty of having spent so much time on the mobile version is that it’s not just an okay state to serve IE, it’s actually a really nice one! The site is all fluid and built with min-width media queries to size the site up from mobile as opposed to down from desktop.

Designed in the browser

Other than to process some portfolio images and create the dotted background image, Photoshop wasn’t used once. We built the whole site in the browser. The interesting thing about our process though was that Sam doesn’t code, but nor was he Photoshopping.

As he was learning the theory of exciting techniques in 2011 web design, he was applying them just as fast in order to art direct the design and build. He switched on to the idea of progressive enhancement and mobile first instantly so he didn’t struggle to adapt to a new way of thinking. He called the shots, saw how designing in the browser allowed us to test, iterate, drop and ultimately refine and create his ideas. Such a lean and neat process. He didn’t get precious about things, he didn’t beat a dead horse, he suggested, we tried, we reworked, we settled on the most pragmatic options.

So yeah, quite a fun and productive hack-weekend, if a little tiring.

Sam, by the way, is a newly freelance designer, so if you need any stuff doing you know where to find him. He’s also on Twitter at @sam_penrose.

Demo

The demo features photos of me, taken on various mountains by Suze. Cheers to her for the content.

The fluidity

Making a carousel fluid is actually ridiculously simple. Let us assume you have five panels. Remember that number!

A carousel is made up of three basic components:

1. A viewport
2. A wrapper for the panes
3. A pane

Thus, our markup is:

<div class=carousel>

  <ul class=panes>

    <li>
      <h2>Pane 01 title</h2>
      <img src=pane-01.jpg alt="">
    </li>

    <li>
      <h2>Pane 02 title</h2>
      <img src=pane-02.jpg alt="">
    </li>

    <li>
      <h2>Pane 03 title</h2>
      <img src=pane-03.jpg alt="">
    </li>

    <li>
      <h2>Pane 04 title</h2>
      <img src=pane-04.jpg alt="">
    </li>

    <li>
      <h2>Pane 05 title</h2>
      <img src=pane-05.jpg alt="">
    </li>

  </ul>

</div>

Now, the viewport defines what we see, we slide our panes behind it and they poke through, like this:

The red denotes the viewport (and incidentally a single pane), the blue denotes the whole five panes behind the viewport.

We just slide these behind the viewport to show a certain amount at a time, et voilà; carousel. But, you all know how carousels work, right…?

To make this fluid is so simple. The viewport needs to fill its container, so this gets width:100%;. Easy.

One pane needs to fit nicely in the viewport, so this needs to occupy 100% of the viewport. With this in mind…

We have five panes, remember, so the ul needs a width of 500%. Five panes that are each the same width as the viewport gives us a width of 500%.

Now we know:

.carousel{
  width:100%;
}
.panes{
  width:500%;
}

So if .panes holds five panes, each pane should be 20% its width. This is where it might get a little confusing…

The viewport is 100% width, the wrapper is five times as big as that and each pane is one fifth the width of the wrapper.

Our code is left at:

/*------------------------------------*\
	$CAROUSEL
\*------------------------------------*/
.carousel{
    overflow:hidden;
    width:100%;
}
.panes{
    list-style:none;
    position:relative;
    width:500%; /* Number of panes * 100% */
    overflow:hidden; /* This is used solely to clear floats, it does not add functionality. */

    -moz-animation:carousel 30s infinite;
    -webkit-animation:carousel 30s infinite;
    animation:carousel 30s infinite;
}
.panes > li{
    position:relative;
    float:left;
    width:20%; /* 100 / number of panes */
}
.carousel img{
    display:block;
    width:100%;
    max-width:100%;
}
.carousel h2{
    font-size:1em;
    padding:0.5em;
    position:absolute;
    right:10px;
    bottom:10px;
    left:10px;
    text-align:right;
    color:#fff;
    background-color:rgba(0,0,0,0.75);
}

The basic equation for making a carousel with any number of panes is:

.carousel{
  width:100%;
}
.panes{
  width:100 * number of panes%;
}
.panes > li{
  width:100 / number of panes%;
}

So, a four-pane carousel would be:

.carousel{
  width:100%;
}
.panes{
  width:400%;
}
.panes > li{
  width:25%;
}

It really is that simple. That’s all there is to making a fluid carousel.

CSS powered

Okay, in this carousel I decided I was going to power it with CSS. This is super unorthodox so if you’re yelling WTF at your screen please read on!

It was going to be (and actually is) used on my good friend Sam Penrose’s new design portfolio, so knowing we had free reign and a little chance to experiment I decided to opt for a pure CSS solution.

This is simple in theory but the maths gets so tricky.

All we do is animate .panels from right to left then back again. We animate for a bit, we pause, we animate again, pause again and so on until it’s done. Then we loop it infinitely.

The CSS is:

@keyframes carousel{
    0%    { left:0; }
    11%   { left:0; }
    12.5% { left:-100%; }
    23.5% { left:-100%; }
    25%   { left:-200%; }
    36%   { left:-200%; }
    37.5% { left:-300%; }
    48.5% { left:-300%; }
    50%   { left:-400%; }
    61%   { left:-400%; }
    62.5% { left:-300%; }
    73.5% { left:-300%; }
    75%   { left:-200%; }
    86%   { left:-200%; }
    87.5% { left:-100%; }
    98.5% { left:-100%; }
    100%  { left:0; }
}

The numbers are so tricky to work with and if anyone can come up with a decent equation to describe it I would be so happy. I’ve got Nick on the job, but I’ve not worked it out yet; I can’t quite grasp the relation between five panes and the numbers above in a way that I could do some quick maths to work out the animations for a four-pane carousel.

The problem is that you have to know how many full moves and pauses are needed for a full iteration of the carousel (before it starts on its infinite loop), and then how to evenly space these numbers between 0 and 100%. My animations last for 1.5% and pause for 11%, these numbers are perfect for adding up to 100%.

Update

Massive thanks to Clay who’s worked out that the number of steps is 4n-3 and that the total time between start of one animation and the next is 100 / 2(n-1) (where n is the number of panes). See his full comment.

But, the code above will sort you out a perfect animation for a five panes so feel free to nab it! I’ll update if and when I crack some maths!

Wait, CSS?!

Using CSS for this is really, really unorthodox so comes with some massive caveats.

Do not use CSS to animate this carousel if:

1. You require the contents of every pane to be visually accessible to the user.
2. You require full browser support.
3. You do not require interactions (like stopping the animation or clicking between panes).

If you are going to use this CSS-only method then ensure that:

1. The user can still use the site fully without the contents of the panes.
2. You are okay with older browsers not animating and just displaying the first pane.
3. You do not want or require users to be able to interact with the carousel.

If you can’t use CSS then combine the fluidity above with plain ol’ trusty JS.

I will happily say that the fluidity is the most important, useful and impressive thing about this technique. Until I, or anyone, can get you a decent equation to substitute your numbers into, the CSS animations are too cumbersome and restrictive to be of large-scale use to most people.

Demo

I won’t write everything up because a view of the source and CSS should explain everything.

Luke did not commission this work, so please don’t reuse the icons or copy this without permission from the respective people. I allow full use of my code (with attribution) but please don’t copy Luke’s format for social icons—the code is mine but its implementation on social icons is Luke’s.

In short, you can have my code but it was Luke’s idea.

/*------------------------------------*\
	BORDERS
\*------------------------------------*/

/* Create a series of empty pseudo-elements... */
html:before,html:after,body:before,body:after{
	content:"";
	background:#dad8bb;
	position:fixed;
	display:block;
	z-index:5;
}

/* ...and position them! */
html:before{
	height:10px;
	left:0;
	right:0;
	top:0;
}
html:after{
	width:10px;
	top:0;
	right:0;
	bottom:0;
}
body:before{
	height:10px;
	right:0;
	bottom:0;
	left:0;
}
body:after{
	width:10px;
	top:0;
	bottom:0;
	left:0;
}

I have a very aggressive and die-hard approach to progressive enhancement which I guess is to thank, in part, for the rule itself.

Let’s start with a very basic and tongue-in-cheek example. Let’s imagine your client comes to you and says ‘Hi, yeah, I love the site but can we make all the links, headings and image borders the same colour as my chihuahua’s eyes?’ … ‘Well sure, you can, but it’ll take an hour at £xxx and I don’t think that it’s going to bring enough user attention, or even be noticed enough—if at all—to warrant the time it’ll take me to do and the money it’ll cost you to have it done.’ In other words, the implementation is not proportional to the appreciation.

Now this is a very stereotypical and clichéd client-from-hell example, but it does paint a picture of how the rule works; will the time it takes you to change something, or add a feature, reap enough benefits to make it worthwhile?

You can’t really feed this equation any numbers, of course, but that’s where it’s up to you to decide what is the cut off point. If you think that the amount of time it will take you to add a feature is worthwhile and will have a proportional appreciation then that’s your choice, and whilst it may not be the same outcome as the agency down the road, it’s you who is building that website.

A more realistic example was during a build I was on with at work. I saw something in a PSD that I thought was missable enough not to fulfil the implementation ∝ appreciation rule; the time it would have taken me to code a robust, <IE7 solution would have been far greater than the amount of time any user would have spent thinking ‘Wow, I’m glad he did that!’

I had no metrics here, I wasn’t able to say ‘this will take me 45 minutes to get working in IE7 and below and will only be appreciated 0–0.8 seconds by any given user’, but sometimes you just know what is sensible and what isn’t.

I guess that’s part of the beauty of the implementation ∝ appreciation rule; you decide its metrics and make them work for you.

I guess also, given the right account or project manager, a ‘more quantifiable’ or rational, measurable and reasonable stance such as the implementation ∝ appreciation rule could well be a more diplomatic and sensible way to steer clients toward taking the progressive enhancement route; something which nigh on all developers would love!

I think an approach such as this is best introduced either on your own personal projects, or on builds where your clients is okay with progressive enhancement (which, hopefully, they all are!). After that I guess it would be time to introduce your most stubborn clients to it. After all; more often than not you’re building sites for your clients’ clients. Just because your client thinks dog-eye-blue links look cool does not mean to say their clients and users will, and they’re the ones that matter…

Furthermore, money talks. Being able to say ‘this will cost you £xxx and is almost certainly not going to make you a single penny’ (politely, of course) can often be enough to steer even the most headstrong client.

And of course, even if something does not fulfil the rule and your client is still insistent on a piece of work being done; they’re paying you! Even if it makes no sense to you, or in the eyes of the equation, just see it as extra cash!

So I don’t suppose I’ve said anything new here, rather I’ve just offered a semi-quantifiable way to justify a more progressive approach to working for and with your clients. If a user won’t appreciate or even notice it then why bother wasting time and money on it?

The implementation must be proportional to the appreciation.

Demo

We also have a daytime version!

First off, look at the demo in IE8 or Firefox, then in Chrome or Safari (i.e. non-Webkit, then Webkit).

In Firefox you should see a series of snowflakes randomly sized and placed across the screen. In Webkit, you should see these snowflakes falling, all at different speeds. We also have a repeat-x background image of some snow running across the bottom of the browser window.

The code

We use a lot of PHP to create the random effects applied to the snowflakes, and also automate a lot of the legwork needed to create 65 unique classes, it’s commented as shown and should make total sense.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>Let it snow</title>
  <link rel="stylesheet" type="text/css" href="css/style.css" />
  <style type="text/css">

    <?php //If the day parameter is set, use a different background ?>
    <?php if(isset($_GET['time']) && $_GET['time'] == 'day') { ?>
    html{
      background:url(img/css/snow.png) bottom left repeat-x fixed #b4c8cc;
    }
    <?php } ?>

    <?php //Number of snowflakes -- you decide! ?>
    <?php $snowflakeCount = 65;  ?>

    <?php //Create a unique class for each of the snowflakes and assign each one a random size and animation duration ?>
    <?php  for($i = 1; $i <= $snowflakeCount; $i++) { ?>
      .snowflake-<?php echo $i ?>{
        <?php //Create a random decimal number between 1 and 10: ?>
        -webkit-animation-duration:<?php echo (rand(10,100) / 10); ?>s;
        <?php //Create a random decimal number between 0.1 and 2: ?>
        font-size:<?php echo (rand(1,20) / 10); ?>em;
      }
    <?php } ?>
  </style>
</head>

<body>

  <div id="wrapper">
    <h1>Let it snow!</h1>
    <p><a href="/2010/12/let-it-snow/">Return to article.</a></p>
  </div>

  <div id="snow">
    <?php //Loop through your chosen amount of snowflakes and make that many empty spans (with associated class) and randomly place them on-screen ?>
    <?php for($i = 1; $i <= $snowflakeCount; $i++) { ?>
      <span class="snowflake snowflake-<?php echo $i; ?>" style="top:<?php echo rand(1,98); ?>%; left:<?php echo rand(1,98); ?>%"></span>
    <?php  } ?>
  </div>

</body>
</html>

Basically we use PHP to create 65 empty <span>s which are then randomly placed and sized on the page. We also give each one a random -webkit-animation-duration so as to ensure they fall at different speeds. Two points worth noting:

<?php //Create a random decimal number between 1 and 10: ?>
-webkit-animation-duration:<?php echo (rand(10,100) / 10); ?>s;
<?php //Create a random decimal number between 0.1 and 2: ?>
font-size:<?php echo (rand(1,20) / 10); ?>em;

Thanks to Dan Bentley for his PHP input here-and-there—mine is a tad rusty.

Here we use rand(10,100) to create a random whole number between ten and one hundred (let’s say 75). We then divide this by ten to get a decimal (i.e. 7.5) to use as the duration in seconds.
We then use rand(1,20) to create a random number between one and twenty (say, 5) which we then divide by ten to get a decimal (i.e. 0.5) for the font-size in ems.

The CSS

/*------------------------------------*\
  MAIN
\*------------------------------------*/
html{
  font-family:Calibri, Arial, Verdana, sans-serif;
  background:url(../img/css/snow.png) bottom left repeat-x fixed #222;
  color:#fff;
  text-shadow:1px 1px 1px rgba(0,0,0,0.5);
  height:101%;
}
body{
  width:940px;
  padding:10px;
  margin:0 auto;
}
#wrapper{
  position:relative;
  z-index:5; /* Bring the content over the snowflakes */
}
h1{
  font-weight:bold;
  font-size:1.5em;
  margin-bottom:20px;
}
a{
  color:#fff;
}

/*------------------------------------*\
  SNOWFLAKES
\*------------------------------------*/
/* Set up a blank canvas in which to house the snowflakes */
#snow{
  position:fixed;
  top:0;
  right:0;
  bottom:0;
  left:0;
  overflow:hidden;
}
.snowflake{
  text-shadow:none;
  position:absolute;
  top:0;
  /* Set up the animation */
  -webkit-animation-name:snowflake-animation;
  -webkit-animation-iteration-count:infinite;
  -webkit-animation-timing-function:linear;
}
/* Fill the empty span with a snowflake-like asterisk */
.snowflake:before{
  content:"*";
}
@-webkit-keyframes snowflake-animation{
  /* Start at the top */
  from{
    top:0%;
    -webkit-transform:rotate(0deg);
  }
  /* Rotate by 360 degrees up until the half way point */
  50%{
    -webkit-transform:rotate(360deg);
  }
  /* Animate to the bottom whilst rotating back to zero */
  to{
    top:100%;
    -webkit-transform:rotate(0deg);
  }
}

The CSS, again, is extremely straightforward and self-explanatory. Use content:""; to keep our code a little cleaner, and animate all the snowflakes top-to-bottom whilst rotating them. Simple!

So there we’ve put a new-age spin on a very dated (and still pretty garish) technique.

Addendum

Following this Twitter conversation between Danny Banks and myself the #snow <div> was introduced. Cheers for the heads-up, Danny!

The only technical downside I can see here is the necessity for that class. Using a simple attribute selector we can ditch that and basically say ‘if any element has a title, put that title after it in CSS’. By simply using [title] over .tooltip we can automate the process and trim some bytes, thus:

<a href="http://twitter.com/jackosborne" title="Follow Jack Osborne on Twitter">Jack Osborne</a>

[title]{
	position:relative;
}
[title]:after{
	content:attr(title);
	color:#fff;
	background:#333;
	background:rgba(51,51,51,0.75);
	padding:5px;
	position:absolute;
	left:-9999px;
	opacity:0;
	bottom:100%;
	white-space:nowrap;
	-webkit-transition:0.25s linear opacity;
}
[title]:hover:after{
	left:5px;
	opacity:1;
}

And in doing so we will cover:

• Design and build a semantic, accessible and sensible progress bar.
• Utilise the much underused method of styling page-specific elements based on their IDs.
• Style the numbers in an ordered list!
• Progressively enhance it with some CSS3.
• Optimise it for mobile.

N.B. This article isn’t so much about a progress bar, but more an illustration that best practices and more advanced techniques can be applied to even the most insignificant aspects of a build to create something awesome!

Design and build

Let us assume the brief is this:

We require a numbered progress bar to indicate user location (past, current and future) during a checkout path on the OurService™ website. It must:

• Be fully accessible.
• Provide a section title with supporting information.
• Highlight the user’s current location in the process.
• Be navigable.
• Work on mobile devices.

The design, let’s assume, is predefined. It looks as above, purely because it has to. The design is not the major focus of this article, the code and techniques are.

“Code what you consume, not what you see.”

Design

The progress bar shall be a linear, left to right series of linked labels. Current location shall be indicated by a change in colour, progression onto the next step shall be indicated by an arrow.

Build

For the purposes of this tutorial we shall assume the current page is the payment page.

One school of though I find invaluable when it comes to sensible and semantic builds is code what you consume, not what you see. This is a very broad generalisation but works for the most part. Code content independently of (and before you consider) coding any styles. Web development basics, but fundamental to web standards and progressive enhancement.

So, what are we consuming? It’s an ordered list of steps which indicate location in a process.

Okay so first off we know we need an <ol> as this list has fixed and definite order. We also require titles and supporting copy for each item. As the titles and supporting copy require separation from one another we are going to wrap the titles in a <span>; a generic inline container. This leaves us with:

<body id="payment-page">

  <ol id="progress">

    <li class="details-step">
      <a href="#">
        <span>Your details</span>
        Name, email, address.
      </a>
    </li>

    <li class="account-step">
      <a href="#">
        <span>Create account</span>
        Username and custom URL.
      </a>
    </li>

    <li class="products-step">
      <a href="#">
        <span>Product options</span>
        Choose your package.
      </a>
    </li>

    <li class="payment-step">
      <a href="#">
        <strong>
          <span>Payment</span>
          PayPal, or credit card.
        </strong>
      </a>
    </li>

    <li class="go-step">
      <a href="#">
        <span>Go!</span>
        Start using OurService™
      </a>
    </li>

  </ol>

</body>

There are a few things in this code which I’ve not yet mentioned, one is the ID on the <body>, another being the class on each <li> and the last being the <strong> wrapped around the payment page’s text. I shall explain these next.

<body> ID and list item classes

A combination of an ID on the <body> and a class on a list item can allow you to know what the current page is. The CSS #payment-page .payment-step{} will target the payment section of the progress bar when it is on the payment page in the process. Similarly, #go-page .go-step{} will target the go item on the go page. I wrote a much more in-depth article on this over at Venturelab.

The <strong> around the payment step’s text

If you’re determining current page programatically, one could argue inserting a class="current" on the relevant item. This is doable, but avoiding such a class name is far nicer.

As stated earlier we are assuming the current page to be the payment page. Now, we can style the current step on any page using CSS, as outlined above, however how would a user with styles disabled be able to tell what the current page is? How can we highlight this for those users?

Well the solution would be to programatically wrap a <strong> around the text on that page, undo the bolding effects with CSS for browsers with styles enabled, and allow people viewing unstyled content to see that the bolded item is the current page. This gives us:

As you can see, users with styles disabled can clearly see the current link is the bolded one, this makes the progress bar that little bit more accessible to those who might need it.

So there we have it, the markup that powers the whole thing.

Styling

Now to style this thing up. First off we’ll look at the very basic CSS, and that alone:

/*------------------------------------*\
  MAIN
\*------------------------------------*/
html{
  height:101%;
}
body{
  font-family:Calibri, Arial, Verdana, sans-serif;
  background:#fff;
  color:#88979e;
  width:940px;
  padding:10px;
  margin:0 auto;
}

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  list-style:none; /* Remove the bullets */
  float:left; /* Make its width equal to the combined width of the items inside it */
  margin-bottom:20px;
}
#progress li{
  float:left; /* Stack them all up left */
  font-size:0.75em; /* Make the entire item smaller */
  font-style:italic; /* Make the entire item italic */
}
#progress a{
  display:block;
  text-decoration:none;
  padding:10px 25px 10px 10px; /* Padding to accomodate background image */
  background:#7b8d77;
  color:#fff;
}
#progress span{
  font-size:1.333em; /* Bring the size of the title only back up */
  font-weight:bold;
  display:block;
  font-style:normal; /* Undo the italics */
}
#progress strong{
  font-weight:normal; /* Remove the bolding for CSS enabled browsers */
}
#progress a:hover{
  text-decoration:none;
}
#progress a:hover span{
  text-decoration:underline; /* Underline the title on hover */
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d; /* Arrow image on the current step */
}
#go-page .go-step a{
  background:#a49d4d; /* Arrow image not needed on final step, colour only */
}

All of the above is very obvious, it is essentially just like creating a normal navigational menu, and gives us this:

Styling numbers in ordered lists

Next up we style the numbers in the ordered list by using the very very useful and much unknown CSS counter module. Because you have such limited control over the appearance of your bullets in (ordered) lists they can be a pain to style. This pain is alleviated somewhat when using an unordered list as you can simply use a background image. It is an altogether different story when you’re using an ordered list as the bullet needs to change with each list item.

What we do here is use CSS to do a very prog-like job; we get it to loop through each item in a parent container and then increment a user-defined value each time it encounters a specified child. Sounds Greek? Read this.

Once we have this number available to us we use the CSS :before pseudo-element and the content:; property to insert the number before each item. How cool is that?!

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  list-style:none;
  float:left;
  margin-bottom:20px;
  counter-reset:step; /* Set up name of increment on parent */
}
#progress li{
  float:left;
  font-size:0.75em;
  font-style:italic;
}
#progress a{
  display:block;
  text-decoration:none;
  padding:10px 25px 10px 30px; /* Padding changed to 30px to accomodate number */
  background:#7b8d77;
  color:#fff;
  position:relative; /* Relative position to allow absolute positioning later on */
}
#progress span{
  font-size:1.333em;
  font-weight:bold;
  display:block;
  font-style:normal;
}
#progress strong{
  font-weight:normal
}
#progress a:hover{
  text-decoration:none;
}
#progress a:hover span{
  text-decoration:underline;
}
#progress li a:before{
  counter-increment:step; /* Increment the step on each occurance of this (pesudo) element */
  content:counter(step); /* Write out value of the increment */
  text-align:center;
  font-weight:bold;
  position:absolute; /* Position number */
  top:50%;
  left:5px;
  margin-top:-8px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d;
}
#go-page .go-step a{
  background:#a49d4d;
}

This then gives us this:

Progressively enhancing

Now for the CSS3 progressive bits:

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  background:#7b8d77; /* Give the ol a background to prevent white showing through behind the items' round corners (change value to #f00 to see what I mean) */
}
#progress{
  -moz-border-radius:5px;/* Round all corners of the progress bar */
  -webkit-border-radius:5px;
  border-radius:5px;
}
#progress a{
  text-shadow:1px 1px 1px rgba(0,0,0,0.25); /* A small text-shadow */
  -moz-border-radius:5px 0 0 5px; /* Round the top- and bottom-left corners */
  -webkit-border-radius:5px 0 0 5px;
  border-radius:5px 0 0 5px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d;
}
#progress .go-step a{
  -moz-border-radius:5px; /* Round all corners of the final step */
  -webkit-border-radius:5px;
  border-radius:5px;
}

The full, combined CSS for the progress bar so far is:

/*------------------------------------*\
  MAIN
\*------------------------------------*/
html{
  height:101%;
}
body{
  font-family:Calibri, Arial, Verdana, sans-serif;
  background:#fff;
  color:#88979e;
  width:940px;
  padding:10px;
  margin:0 auto;
}

/*------------------------------------*\
  PROGRESS
\*------------------------------------*/
#progress{
  list-style:none;
  background:#7b8d77;
  float:left;
  margin-bottom:20px;
  counter-reset:step;
  -moz-border-radius:5px;
  -webkit-border-radius:5px;
  border-radius:5px;
}
#progress li{
  float:left;
  font-size:0.75em;
  font-style:italic;
}
#progress a{
  display:block;
  text-decoration:none;
  padding:10px 25px 10px 30px;
  background:#7b8d77;
  color:#fff;
  text-shadow:1px 1px 1px rgba(0,0,0,0.25);
  position:relative;
  -moz-border-radius:5px 0 0 5px;
  -webkit-border-radius:5px 0 0 5px;
  border-radius:5px 0 0 5px;
}
#progress span{
  font-size:1.333em;
  font-weight:bold;
  display:block;
  font-style:normal;
}
#progress strong{
  font-weight:normal
}
#progress a:hover{
  text-decoration:none;
}
#progress a:hover span{
  text-decoration:underline;
}

#progress li a:before{
  counter-increment:step;
  content:counter(step);
  text-align:center;
  font-weight:bold;
  position:absolute;
  top:50%;
  left:5px;
  margin-top:-8px;
  padding:2px 6px;
  background:rgba(0,0,0,0.25);

  -moz-border-radius:20px;
  -webkit-border-radius:20px;
  border-radius:20px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a{
  background:url(../img/css/splitter.gif) right center no-repeat #a49d4d;
}
#go-page .go-step a{
  background:#a49d4d;
}
#progress .go-step a{
  -moz-border-radius:5px;
  -webkit-border-radius:5px;
  border-radius:5px;
}

Which, when coupled with the markup, gives this:

Recap

So, let’s cover what we’ve done so far. We’ve:

• Coded up a semantic progress bar (using an ordered list and correct generic elements).
• Made it accessible (addition of the strong around the content for non-CSS browsers).
• Styled it all up.
• Made use of the body ID trick to mark the current page.
• Used CSS counters to style the numbers of an ordered list
• Progressively enhanced it all to make it a little easier on the eyes.

Mobile optimisation

For more information on mobile/iPhone optimised sites please see my associated article.

Next up we need to optimise this thing for mobile. This couldn’t be simpler. The key to optimising sites for mobile is linearise. Linearise everything.

In your markup, add this line to the <head> section, thus:

<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>Progress</title>
  <meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />
  <link rel="stylesheet" type="text/css" href="css/new-style.css" />
</head>

This tells the user agent that the viewport should be the same as the device’s own screen-size, that it should be initially set to a scale of 1 (i.e. no scale), its maximum scale is set to 1, and that users can’t scale themselves.

Now, add the following to the very end of your CSS file:

/*------------------------------------*\
	MOBILE
\*------------------------------------*/
@media (max-width: 480px){ /* In any browser narrower that 480px... */
body{
	width:auto; /* Give the body a fluid width... */
	padding:5px; /* And a slight padding */
}
#progress{
	width:auto; /* Give the list a fluid width */
	background:none; /* Remove the list's background... */
	float:none; /* ...and float */
}
#progress li{
	float:none; /* Remove list item float, causing them to stack */
	margin-bottom:1px; /* Space them slightly */
}
#progress a{
	margin:0 10px; /* Indent the left and right of each item by 10px */
	-moz-border-radius:5px; /* Round all corners */
	-webkit-border-radius:5px;
	border-radius:5px;
}
#details-page .details-step a,
#account-page .account-step a,
#products-page .products-step a,
#payment-page .payment-step a,
#go-page .go-step a{
	background:#a49d4d; /* Set the background of the current item */
	margin:0 auto; /* Remove the 10px indent to show that the step is current */
}
}

Now, if you want to test this and don’t have a smartphone, or haven’t got this hosted in a live environment, simply resize your browser window right down until you see the change. I tend to use the Firefox Web Developer Toolbar addon to resize the window to 480×800px.

On the iPhone this now looks like:

Demo

For the full working demo head to http://csswizardry.com/demos/progress-bar/. For the complete CSS (with reset) please see http://csswizardry.com/demos/progress-bar/css/style.css. Also, try using Firebug to change the <body>’s ID to go-page.

Final words

As I stated previously, this article isn’t so much about the progress bar itself. What I hope this article has shown is how something as small and trivial as a progress bar has a wealth of little nooks and crannies in which to immerse yourself. Semantics, accessibility, using <body> IDs to style current states without a class="current", how to use CSS counters to style the numbers in an ordered list, how to progressively enhance lean markup, and how to optimise things for mobile in a flash.

All of the above skills are easily and quickly transferable. It might be a progress bar today, but what could it be tomorrow? Skills like the ones covered here give you the potential to make something great, out of something very very simple.

A little background

N.B. I am in no way saying we invented the concept of designing in the browser, we merely adopted it very early, before most.

I have championed designing in the browser long before it became popular. True fact. I was doing this long before it was a mainstream practice.

When working at Sense I was extremely lucky to work alongside a man called Philip Meitiner. He was Sense’s Account Director and a genuine pleasure to work with and learn from. It was whilst we were working on a white-label website for some big name clients (Nissan, Renault, Mercedes, Volvo and more…) that we decided to ditch Photoshop and dive straight into the browser. This idea was born from the fact that I’d put together a series of HTML wireframes whose code was of a quality that I deemed suitable for production. It seemed backward to us to then fire up Photoshop and design an image based on a set of HTML pages, to then return to the HTML and style it.

Thus was born our idea to design in the browser. We saved the HTML in isolation and used it as a starting point for each development of the various sites we had to build. We branded and designed each white-label in the browser and sent live, actual code back to the client for approval. It was, for everyone involved (though me more so) a dream come true.

The article I wish I’d written

Months later, 24 Ways published their article on designing in the browser. If there was one article I wish I’d written, it’s that one. Phil was equally dismayed, however at least we knew we were on to something good.

How it works

For those not in the know, designing in the browser is exactly as it sounds. Instead of building a website in Photoshop then markup, you dive straight into the browser and notepad and get cracking. A few benefits:

• Saves time, cutting all Photoshop work.
• Changing repeated elements (e.g. hyperlink colours) takes just one CSS declaration in the browser. It takes a lot of donkey work in Photoshop.
• Clients buy websites, not printouts of websites. Designing in the browser allows them to see how their site looks in its intended environment.
• This makes progressive enhancement usage much simpler. If they view it in Chrome, they see your round corners. If they view it in IE they see square corners. Both are intended behaviours, and both are fine.
• It can show things like hover effects and interactions that Photoshop can’t.

“Clients buy websites, not printouts of websites.”

How it improves build quality

There are a few reasons why I believe that designing in the browser improves the overall build quality of a website.

Users don’t (generally) visit a website for its design, they visit for its content. Designing in the browser considers content first. This is absolutely essential for a well thought out website, in my opinion. In Photoshop you design a layout and then populate it with content. Designing in the browser you start with your content and design around it. Content is the focus and the design does nothing but complement it. You’re coming up with a suitable way to house the content you’re starting out with, rather than shoehorning content into a preconceived design.

By focussing on what your users are actually coming for, you often find that a better UX will follow. Ignore anything extraneous to begin with, nail the fundamentals (hint: typography!) and concentrate on how pretty it looks after. Designs change more frequently than content does; invest in the content early.

“What happens when your Photoshop printout uses nice anti-aliased Helvetica, and the final site renders in non-aliased Arial on the client’s machine?”

Another reason is that, particularly if you are in a team where the designers don’t do a lot of hands-on coding and build, devoting a lot of code to purely visual effects and design can lead to insensible builds, insemantic markup and a whole host of other issues. This is, admittedly, a marginal chance, but coding around the content before the design will often lead to more sensibly built websites, focussing more effectively on its content.

The main time to use the designing in the browser as your primary build method is probably with a lot more sites than you’d imagine. Blogs, ecommerce, portfolios, news sites, apps, aggregators. You name it.

Designer to developer

Hopefully this one doesn’t happen often, but it can do…

I’m sure developers have had this countless times–a designer brings you a design that just isn’t codable. The client had been shown a PSD that you have no hope of coding unless you botch and hack at markup and use ridiculously extraneous amounts of Javascript to manipulate it. By designing at code level you avoid all these problems from the outset. What you code is your design, your design is codable.

Designers obsolete?

Far from it. The designer is often the developer anyway, and if not, the designer is needed to call the creative shots and create initial visuals. Take Venturelab for example. Si came up with the skeleton of that design in Photoshop. Any type work, any calls-to-action, lists, navigation and tables were done by me, in the browser. Si created two ‘mood board’ style PSDs (and very good ones at that) but Justin was only ever shown working code, designed in the browser.

Nail the backbone in Photoshop if needs be, but in areas where rapid development and the need for quick and arbitrary changes are needed (think typography and link colours etc.) designing in the browser is far more efficient. Imagine the pain of changing the zebra-stripe colours of a giant table in Photoshop when you just edit one CSS declaration and see to it all in one go.

On pushing the limits

There have however been one or two occasions in my career where not designing in the browser has done more good for a project than bad.

“There’s a large chance that [a developer working in the browser] won’t make things difficult for themselves, that they won’t push their boundaries. This is a bad thing.”

The first example links back to what I said about designers handing sites to developers that the developers can’t code. If the person designing the site is also the person building it, there is a (pretty large) chance that they’ll take the easiest simplest route to completion. There’s a large chance that they won’t make things difficult for themselves, that they won’t push their boundaries. This is a bad thing.

If I draw on my own experience, the Findus Crispy Pancakes site is an excellent example of designers giving developers the kind of headaches we love. I built Findus about a year or so ago whilst at Sense. Rob designed the site in Photoshop and when I saw it I nearly fainted. I had no idea where I’d even start coding up such a complex looking, overlapping, quite frankly mental design.

Yet despite this, I got my developers brain on and got to work. I finished the site about four days ahead of schedule and enjoyed every minute of it. That design pushed me more than it would have if it had started out in the browser. It was a lot better for being in Rob’s hands first. And I still maintain that it was one of my most challenging builds to date (IE6 support…).

Developers still need designers!

Follow Rob on Twitter. Fantastic designer and all-round nice guy.

It is important that the designer and developer have overlapping knowledge of each others’ respective areas, yet play to their fullest in their own. The Findus site was a bit of fun on a small project which allowed me and Rob to really stretch ourselves, and that’s what it’s all about.

Big brands

Another couple of times where designing in the browser hasn’t been viable was when we, at Sense, were working on the Travelodge and Rizla websites. Travelodge was designed by another agency anyway, but even so, as they had very stringent brand guidelines that stated that round corners were a pivotal part of the brand, everything needed to be done in Photoshop.

Another example would be Rizla, which, again, we built at Sense. As Rizla’s brand is so important to their success and recognition it could not have just gone straight into the browser. Rizla wasn’t so much about quickly accessible content, so much as heavily designed and branded content. We allowed for users to change the design, and for the design to carry off promotional work, which could not have happened straight in the browser.

Aiding programmers

This section was edited in part by Dan Bentley.

Programmers manipulate markup. A Photoshop document is nigh on totally useless to a programmer, whose involvement lies in all that magic stuff that happens behind the scenes. Allowing programmers access to the code from an earlier point means they can start their job alongside the developer sooner.

Furthermore is the idea that Javascript developers can visualise their involvement much sooner, too, and see what markup they will be manipulating from the outset, rather than having to second guess what markup might result from the developer’s take on the PSD. They can start manipulating the DOM and begin building prototypes alongside the main build developer right from the start, making life easier for them as well.

When do you design in the browser?

At every available opportunity.

It saves time, it’s a much better way of presenting concepts to clients, it leads to better quality builds, it gives more consideration to content, it’s more fun than working in Photoshop (at least from my point of view), it’s easier to experiment, it’s far more efficient and the quality of the code is usually better as it concerns itself with content over decoration.

“Designs change more frequently than content does; invest in the content early.”

For any content-centric sites (I know, all sites are about content) such as blogs, web-apps, CMS style dashboard builds, news sites, informational sites or anything similar, you can’t lose by designing in the browser.

If you’re an account manager type person at an agency, run the idea past your development team; I’m pretty sure they’d love to work like this, if they don’t already.

When can’t it be used?

Sometimes, designing straight in the browser just can’t work. Heavily branded or very graphical sites that are more about decoration or branding than content will be a struggle to create without opening Photoshop first. However, by completing the major chunk of the layout and graphical design in Photoshop, you can often leave it at that, and model/work on type straight in the browser (what happens when your Photoshop printout uses nice anti-aliased Helvetica, and the final site renders in non-aliased Arial on the client’s machine?). For the fine details, designing in the browser will be far more efficient and true-to-life than using Photoshop will ever be. Embrace it, and enjoy it.

Final word

So, do you design in the browser? Are there any reasons why you don’t? Would you like to? Leave a comment and open the debate up a little wider…