My talk covered how to build big, scalable front-ends and one of the key factors involved in doing so is sensible and generous use of abstracted classes. One thing that really helps you achieve this is the application of the single responsibility principle, a method used mainly in OO programming.

Loosely, the single responsibility principle states that every module or chunk of code (a function etc) should do one job well and one job only. The benefits of this are mainly in the way of maintainability and extensibility.

If we don’t adhere to the SRP then we are likely to end up with code which does more than it should, this means that altering one part of that code could negatively impact a seemingly unrelated part of the same snippet. It also makes our code a lot less flexible in that we find our code is trying to do too much; it is too specific in its job to be portable and reusable. Abstracting chunks of functionality into several responsibilities means we can reuse a lot more of our code and recombine it over and over with other similarly abstracted chunks.

The Wikipedia article makes a much better job of explaining than I can so I would recommend giving that a quick read (it’s only short).

Also, you will find that a lot of us do this already, and perhaps without even realising. A class of .wrapper is a good example of the SRP at play; by having a single, reusable class whose sole job it is to group content we make our code a lot easier to work with. We don’t need to apply lots of widths to lots of elements; we use one extra div and delegate the width-constraining responsibility to that.

We do this because it makes sense, but we don’t do it often enough; if we start actually thinking like this all the time we find we can vastly improve our code…

The SRP is normally applied in programming circles but I have definitely found it is incredibly useful when making lean, scalable front-ends. Here’s a quick example of un-abstracted code that doesn’t follow the SRP:

<!-- HTML -->
<a href=/product class=promo>Buy now!</a>

/* CSS */
.promo{
    display:block;
    padding:20px;
    margin-bottom:20px;
    background-color:#09f;
    color:#fff;
    tex-shadow:0 0 1px rgba(0,0,0,0.25);
    border-radius:4px;
}

Here we have a class for a promotional box of content. Here we are doing two things—we are defining box model and structure and we are defining cosmetics (colouring etc).

We can refactor this code to adhere to the SRP by splitting those two chunks of functionality into two classes:

 <!-- HTML -->
<a href=product class="island promo">Buy now!</a>

/* CSS */
.island{
    display:block;
    padding:20px;
    margin-bottom:20px;
}

.promo{
    background-color:#09f;
    color:#fff;
    tex-shadow:0 0 1px rgba(0,0,0,0.25);
    border-radius:4px;
}

We now have two classes which each carry a single responsibility; .island boxes off content and .promo applies our promotional styling. This now means that we can do things like this, which previously we couldn’t:

 <!-- HTML -->
<h2>Buy now with promo code: <span class=promo>0MG4WE50ME</span></h2>

Previously we couldn’t have managed this as the .promo class also carried a lot of box model; by abstracting our code into single responsibilities we can pick and choose what we want to use and where a lot more easily.

We can take this much, much further; now we also have a generic class for boxing off content! Where we once might have had:

<!-- HTML -->
<div id=header>
</div>

<div id=content>
</div>

<div id=sub-content>
</div>

<div id=footer>
</div>

/* CSS */
#header{
    padding:20px;
    margin-bottom:20px;
    background-color:#121416;
    color:#fff;
}

#content{
    width:640px;
    float:left;
    margin-right:20px;
    padding:20px;
    margin-bottom:20px;
}

#sub-content{
    width:280px;
    float:left;
    padding:20px;
    margin-bottom:20px;
}

#footer{
    padding:20px;
    margin-bottom:20px;
    background-color:#e4e4e4;
    color:#333;
}

We would now have:

<!-- HTML -->
<div class="island header">
</div>

<div class="island content">

    <h2>Buy now with promo code <span class=promo>0MG4WE50ME</span></h2>

</div>

<div class="island sub-content">

    <a href=product class="island promo">Buy now!</a>

</div>

<div class="island footer">
</div>

/* CSS */
.island{
    display:block;
    padding:20px;
    margin-bottom:20px;
}

.promo{
    background-color:#09f;
    color:#fff;
    tex-shadow:0 0 1px rgba(0,0,0,0.25);
    border-radius:4px;
}

.header{
    background-color:#121416;
    color:#fff;
}

.content{
    width:640px;
    float:left;
    margin-right:20px;
}

.sub-content{
    width:280px;
    float:left;
}

.footer{
    background-color:#e4e4e4;
    color:#333;
}

Because we abstracted our code out we now have a really portable class for simply boxing off content!

N.B. You should also abstract your layout to a grid system, taking the floats and widths off the page components and leaving that responsibility to the grids.

Just some of the benefits of working like this are:

1. Your CSS is a lot DRYer.
2. You can make far-reaching changes to your designs by simply modifying a base abstraction only once.
3. You can make safer changes because you know that when editing a class you are only ever altering one responsibility.
4. You can combine responsibilities to make a variety of components from a lot of abstracted classes.

Now we can take it further still.

Because we have a nice .island class whose sole responsibility is to box off content then we can now do things like this:

<!-- HTML -->
<div class="island content">
    ...
    <form>
        <p class="island error">Please provide your name.</p>
        ...
        <label class=error>Name:</label>
        ...
    </form>
    ...
</div>

/* CSS */
.island{
    display:block;
    padding:20px;
    margin-bottom:20px;
}

.error{
    background-color:#fce0e2;
    color:#c00;
}
.error.island{
    border:5px solid #c00;
    border-radius:4px;
}

Because we have our chunks of CSS only working on one thing at a time then we can reuse and combine useful things time and time again. I’ve written about this before: Class based builds are like eating at Subway.

When to use it?

There’s no definite answer to questions like this but as a general rule try and stick to the SRP any time you think that subsets of a style rule could be split out into more manageable and reusable abstractions. Any time you are coding a potentially repeatable design pattern then try and split it out as per the single responsibility principle.

But!

It’s important not to take this too far; classes should be abstracted but ideally not presentational. Classes like .round-corners for the sake of SRP are really not all that advisable.

When I write HTML and CSS I have a certain set of rules and guidelines I stick to with regards syntax and formatting. I‘ve decided to write them up here not to preach or tell you how to do things, but simply to share how I like to work. If you hate the things I do that’s cool, these are not recommendations. If you like anything I do then great; you can have it. What I would love to see is other people doing the same; please consider writing up your coding styles, nuances and preferences and share them about!

HTML

With HTML5 we have a lot looser syntax which means more scope for experimentation than we were typically used to with XHTML. With things like <li>s not requiring closing, some attributes not requiring quotes, tags not needing to be lowercase and elements like <hr />s not needing to be self-closing, there’s a lot to play with! Here’s what I do with my HTML…

Unquoted attributes

Where I don’t need to, I don’t quote attributes. Where I would have had class="wrapper" I now have class=wrapper. Why? Because I can and I like the look of it!

Obviously, sometimes you do need to quote attributes. If you have multiple classes like class=wrapper header-wrapper then you need quotes. Without quotes the browser sees this as: class="wrapper" header-wrapper="".

To know when you can and when you can’t use quotes then have a tinker with Mathias’ Mothereffing unquoted attribute value validator.

There are instances where you could use unquoted attributes but I choose not to. It’s hard to summarise this in a quick rule so I’ll give an example:

<input type=submit class=btn value=Login>

This is perfectly valid usage of unquoted attributes, however, imagine the client calls up the agency and (very rightly) says Hey, the word Login needs to be Log in, can we change that please? The project manager knows the designer is totally flat out busy and doesn’t have the time for smaller amends at the moment. Because project managers are awesome lovely people (right? Right?!), they decide that they can make this simple change themselves to save the designer a job. They open up the relevant file, see value=Login and simply change it to value=Log in, assuming that’s all there is to it. Now, the PM is likely not a technical person so they won’t necessarily know that this will now need quoting; the designer would have.

So, anywhere where the content of the attribute is subject to arbitrary change, I like to quote the attributes as a backup. Also, any time an attribute is populated dynamically (for example, through a CMS) it is best to quote it just in case; if you aren’t manually and consciously altering the attribute, play it safe and pop some quotes round it…

Now, I know what you’re thinking: If you sometimes have to use quotes then why not always use quotes? It’s more consistent. Well, you’re half right. It is more consistent on the whole, but by introducing rules I make my own consistency; if you can get away with not using quotes, then do so.

No self closing tags

With HTML5 we can write things like <hr /> as <hr>, <img /> as <img> and so on. I choose to omit the />, so in my HTML you’ll see things like:

<meta name=viewport content="width=device-width, minimum-scale=1.0, maximum-scale=1.0">
<link rel=stylesheet href=css/style.css>

Unquoted attributes where I can, and no self closing tags.

Optional closing tags

In HTML5 (or non-XHTML syntax) you can omit actual, full closing tags from certain elements! This means that the following is totally valid:

<ul>
    <li>Lorem
    <li>Ipsum
    <li>Dolor
    <li>Sit
    <li>Amet
</ul>

I don’t write my HTML like this as I’m just not too keen on the look of it… If you want to though, you certainly can.

Whitespace

This one is hard to quantify, but I like to use whitespace to loosely reflect the separation of elements that you might see once rendered. I group and space elements with whitespace as you would expect them to be grouped visually in the rendered page, for example:

<dl>

    <dt>Lorem</dt>
    <dd>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</dt>

    <dt>Ipsum</dt>
    <dd>Vestibulum tortor quam, feugiat vitae, ultricies eget, tempor sit amet, ante.</dt>

    <dt>Dolor</dt>
    <dd>Morbi in sem quis dui placerat ornare. Pellentesque odio nisi euismod in pharetra.</dt>

</dl>
 
 
<div class=promo>

    <p><strong>Pellentesque habitant morbi tristique</strong> senectus et netus et malesuada fames ac turpis egestas.</p>
    <a href=# class=btn>Lorem</a>

</div>

A mixture of no, single and double lines of whitespace help to separate elements, or show their visual relationship to one another. For example, the <dt>s and <dd>s belong with each other, but are separate from other groupings.

Comments on closing tags

After every major chunk of HTML, for example, the end of a carousel, or the end of the content <div>, I place a closing-comment, for example:

<div class=content>

    ...

    <div class=carousel>
    ...
    </div><!-- /carousel -->

    ...

</div><!-- /content -->

This is certainly not uncommon practice, but because all closing tags look the same as each other (they can’t carry the classes that the opening tags do) it’s often nice to leave a comment so you know what element you’re dealing with.

Namespaced fragment identifiers

I came up with this idea to namespace fragment identifiers last year. It’s basically, I think, a nice way to add a little more meaning to your fragment identifiers and give a little bit more of a clue as to what they actually link to.

<a href=#section:fragment-identifiers>Fragment identifiers</a>

...

<div id=section:fragment-identifiers>...</div>

CSS

So far I’ve dealt with how I write HTML, but what about CSS? My CSS is a lot less ‘different’, it’s mainly only formatting and syntax rules here.

No IDs

This is more a technical thing, but I have a blanket-ban on IDs in CSS. There is literally no point in them, and they only ever cause harm. Everything that needs styling is done so without using IDs.

Table of contents

At the top of my CSS files I have a table of contents that maps to the section titles in the document, it looks a little like:

/*------------------------------------*\
    CONTENTS
\*------------------------------------*/
/*
NOTES
RESET
SHARED     Share anything we can across elements.
MAIN       HTML, BODY, etc.
*/

Section titles

I denote each section (layout, type, tables etc) of my CSS thus:

/*------------------------------------*\
    $MAIN
\*------------------------------------*/

This section heading is also prepended with a $. This is so that—when I do a find for a section—I actually do a find for $MAIN and not MAIN. This means that I’m only ever searching within section headings. A search for $MAIN will only ever find me a section with that name whereas a search for MAIN could find me something like:

.s{
    background-image:url(/img/css/sprites/main.png);
}

Being able to search just in the scope of headings is very, very useful.

I also leave five carriage returns between each section, for example:

/*------------------------------------*\
    $MAIN
\*------------------------------------*/
 
 
 
 
 
/*------------------------------------*\
    $TYPE
\*------------------------------------*/

This means that when scrolling quickly through my stylesheet I know that any gaps in the code are likely to be new sections.

The shared section

I wrote about the shared section briefly on Smashing Magazine in my article Writing CSS for others. This is basically a section in a stylesheet where, instead of declaring one rule over and over, we define it once and attach selectors to it, for example:

a,.brand,h1,h2,h3,h4,h5,h6{
    color:#BADA55;
}
h1,h2,h3,h4,h5,h6,
ul,ol,dl,
p,
table,
form,
pre,
hr{
    margin-bottom:24px;
    margin-bottom:1.5rem;
}

Doing this means that things I want to use over and over are only written once, and I can update all instances in one place. It’s kinda like variables in vanilla CSS…

Formatting

I write multiline CSS with a distinct lack of whitespace that most people seem to hate:

.wrapper{
    margin:0 auto;
    max-width:940px;
    padding:10px;
}

No spaces before braces or after colons.

Vendor prefixes

I write vendor prefixes so that the values all line up vertically; this means I can scan them quicker (to check they’re all identical) and I can alter them all in one go if my editor supports typing in columns:

.island{
    padding:1.5em;
    margin-bottom:1.5em;
    -webkit-border-radius:4px;
       -moz-border-radius:4px;
            border-radius:4px;
}

Indenting rulesets

One thing I do like to do is indent my rulesets to mirror the nesting of their corresponding HTML. For example, take this carousel HTML:

<div class=carousel>

    <ul class=panes>

        <li class=pane>

            <h2 class=pane-title>Lorem</h2>

        </li><!-- /pane -->

        <li class=pane>

            <h2 class=pane-title>Ipsum</h2>

        </li><!-- /pane -->

        <li class=pane>

            <h2 class=pane-title>Dolor</h2>

        </li><!-- /pane -->

    </ul><!-- /panes -->

</div><!-- /carousel -->

My CSS for this would be formatted:

/*------------------------------------*\
    $CAROUSEL
\*------------------------------------*/
.carousel{
    [styles]
}

    .panes{
        [styles]
    }

        .pane{
            [styles]
        }

            .pane-title{
                [styles]
            }

By doing this, I can see from the CSS roughly how the HTML should look; I don’t need the HTML in front of me in order to work out what lives in what.

HTML in CSS

In situations where it would be useful for a developer to know exactly how a chunk of CSS applies to some HTML, I often include a snippet of HTML in a CSS comment, for example:

/*------------------------------------*\
    $TOOLTIPS
\*------------------------------------*/
/*
<small class=tooltip><span>Lorem ipsum dolor</span></small>
*/
.tooltip{
    [styles]
}
    .tooltip > span{
        [styles]
    }

Final word

For a loose example of the above, poke through vanilla or the hry.rbrts.me source on GitHub.

Just to reiterate, this is my coding style; I’m not making suggestions or laying down rules here. If you like anything then feel free to adopt it yourself, if you hate it then that’s cool (just hope you don’t inherit one of my projects!)

I’d really love if people wrote up and shared their own; there are loads of different ways of writing code and I’d be really interested to see what other people do. There’s a really good opportunity for learning some really neat tips!

If you do write your own, please tweet it at me with the hashtag #codestyle, that way everyone can easily keep track of any posts.

Unquoted attributes, no self-closing tags, loads of whitespace, weird CSS indenting and a lot of comments; what’s yours?

This is something I learned whilst undertaking the single biggest project of my career so far; the complete (and not-yet-live) rebuild of one of BSkyB’s most trafficked websites. For years I’d been working on medium-sized projects where I strove to use as few classes as possible, my CSS was so elegant and hand-crafted and everything used the cascade. I thought it was beautiful.

I found my old approach isn’t best practice when working on a big site, therefore it’s not best practice at all… You can scale down the big site mentality to smaller builds, you can’t scale up small site mentality to bigger ones. With this in mind, how you’d build bigger sites is best practice, how you tend to build smaller sites is typically (though, as ever, not always) based on fallacy and myth.

I recently rebuilt my friend Sam’s design portfolio site. Typically I’d have used IDs everywhere, not used any OO and not really paid much attention to the length or efficiency of my CSS selectors. This would have worked but only because the site is small. Any attempts by Sam to scale the site up, add pages, move components or alter the layout would have been hampered by these methods. Instead I decided to apply big-site mentality and dropped any IDs, used an OO approach and made sure every component is reusable. The resulting code is incredibly flexible, very efficient and still looks nice.

• OOCSS is always best practice.
• DRY is always best practice.
• Efficiency is always best practice.
• Maintainability is always best practice.
• Flexibility is always best practice.

It doesn’t matter if you’re building the next Facebook or if it’s just a site for the builder down the road; best practice is always best. You might not notice an inefficient selector on a small site, but it doesn’t mean that it’s not still inefficient. Just because you don’t notice something it doesn’t mean it’s not still happening.

Build every site like it’s a 1000 page behemoth because then it can scale; it may never need to, but it can. Building every site like it’s a piece of art, using convoluted selectors and rigid, ID ridden code, it can never scale, even if you want it to.

Your code might look like the Sistine Chapel, but if it’s a chore to maintain, or you find you can’t pick up a component and drop it anywhere with zero worry, then it’s not powerful. Code is about power before prettiness. You might feel dirty at first, but when you realise how nicely things fall into place using proper best practices you’ll see the benefits.

The only person who cares how pretty your code is is you. Your users want fast UIs, your clients want reliable builds and you and your team want code that is easy to maintain 6 months and a dozen client mind-changes down the line.

Best always means best, it has no caveats or conditions.

Further reading

• Our Best Practices are Killing Us by Nicole Sullivan
• OOCSS.org

Anyway, this is my solution, and this is its code.

Basically there are two main parts to this technique; the punching-the-hole-through-the-nav and the masking-the-hole-to-be-a-triangle. Both techniques couldn’t be simpler, and we use pseudo elements to do it.

Punching holes through elements

This whole technique can only work by taking advantage of the behaviours of fixed background images. The exact same background:; applied to two elements give an odd result if both are also fixed. It gives the effect of a hole having been punched right through your page to the background…

What we do here, then, is create a pseudo element with .nav .current a:before and sit this at the bottom of the current list item. We then apply the fixed background to this as well as the page. This is our punched hole already sorted, only it’s square… we want a triangle.

Masking the hole

To mask the hole to appear like a triangle we use another pseudo element and the CSS triangle hack to cover things up.

The triangle hack works by selectively applying borders to zero width/height elements, take a look at this version with the triangles highlighted. All we need to do here is make some of them the same colour as the nav and we’re done!

So, by cleverly using a pseudo element we can spoof a hole through elements and then using a second one we can mask the corners off!

The full, commented CSS:

.nav{
	overflow:hidden; /* To clear floats */
	background:#111;
	margin:0;
	padding:0;
	list-style:none;
}
.nav li{
	float:left;
}
.nav a{
	display:block;
	padding:2em /* <-- This is our magic number, this defines how large our notch can be! */ 1em;
	color:#fff;
	text-decoration:none;
}
.nav a:hover{
	text-decoration:underline;
}
.nav .current a{
	position:relative;
	text-decoration:underline;
	cursor:text;
}
.nav .current a:before,
.nav .current a:after{
	content:"";
	display:block;
	width:2em; /* Must match our magic number... */
	height:2em; /* ...our notch will end up being half this size. We define it in ems to scale it up with the text size. */
	position:absolute;
	bottom:0;
	left:50%;
	margin-left:-1em; /* Half of our magic number. */
}
body,
.nav .current a:before{
	background:url(http://farm5.static.flickr.com/4102/4876702379_82fe2bd7a8_b.jpg) top left no-repeat fixed; /* Apply to the notch and the relevant container (this case, body). */
}
.nav .current a:after{
	width:0;
	height:0;
	border:1em solid #111; /* Half of our magic number and same colours as our nav's background. */
	border-bottom-color:transparent;
}

Drawbacks

There are drawbacks here; you have to have a fixed background image and you have to have a solid background colour for your nav, but they are reasonable trade-offs, considering this doesn’t use any extra markup at all and works in IE8+!

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.

Thanks to everyone who sent a design in! I feel bad that I can’t do them all because the quality was really high. Sorry if I didn’t pick you, a lot more went into the decision than just looks; I needed to consider time-frames, aesthetics, complexity and suitability to the build-along format.

Follow along

Live code

You can watch the actual build take shape by periodically refreshing this page.

Video

I’m actually going to be recording my screen throughout the whole thing, code, Spotify, Twitter, you’ll see it all. I’ll be putting this online a few days after (I won’t be doing a live screen-cast).

GitHub

I’m going to commit build milestones to a GitHub repo periodically so you can see each major step of the build as it happens.

Twitter

Follow me and keep an eye on the #buildAlong hashtag (please also use this for anything you Tweet about the event).

Feel free to Tweet at me whilst I’m working. This should be fun!

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.

Entry is now closed. Thanks all who sent in a PSD, watch this space for a launch article.

Obviously there need to be some terms and conditions. Apologies if these seem a little harsh(ly worded) but they are as follows:

• PSDs only. Sorry, I don’t work with Fireworks enough to make me quick enough for this type of exercise.
• The PSD I choose is my choice. I am only doing one and it’ll most likely be one that’s fun but not mountains of work; I need to be able to do it in a night.
• CSS and HTML only. No Javascript as I don’t know Javascript; you would not want me even attempting it!
• The code I provide will be final. Progressive enhancement will be used, it won’t look the same in every browser, you won’t get to make any change requests or ask for bug fixes after the fact. Naturally I’m going to do a good job, you won’t end up with any messy code, but as this is entirely free I can’t take instruction.
• If you’re, for whatever reason, unhappy with the outcome I’m afraid you’re stuck with it… Whether the final page goes into production or not is entirely up to you.
• The PSD must be all above board; I won’t be building you a new adult dating site ;)
• This one is entirely your responsibility but I strongly advise you are fully transparent if your PSD will be sold on to a client. I have no qualms with you making a profit on my work but make sure your client is cool with it, especially when their site design will be being made totally public.

I’m keen to keep this as informal as possible, but the format will take:

1. If you want me to build your PSD please email a full-size JPG of your design by Wednesday 2 November 2011 to harry at csswizardry dot com with the subject line Build-along. This subject line is vital as I’m going to set up a Gmail rule to group stuff. Any non-conforming emails might get overlooked.
2. I’ll look at the JPGs and choose one to build. I’ll announce the person I choose in a blog post and also email them directly, at which point they reply with their actual PSD file. If your PSD didn’t get chosen then I will not email you I’m afraid; that’d take forever!
3. The PSD must be properly constructed. I don’t want to be battling with any Layer 12 Copy 4 v2 stuff!
4. Make sure you provide any font-files or Typekit etc information if your design uses them.
5. I’m most likely going to be building the PSD on Friday 4 November 2011. The reason for this is that if it keeps me up into the early hours then I’d rather that was on a weekend rather than a work-night. This does mean that if you want to follow along then you’ll have to be in on a Friday evening, no pub!
6. I’ll announce the URL in a blog post and Twitter, you can follow along live.
7. The code will be getting committed to GitHub, too, so make sure you’re okay with that!

This all seems a bit formal, I realise, but it really won’t be. I just need to make sure I have all the stuff in the right place at the right time!

Pop any questions in the comments and I’ll update the post as necessary. Please hashtag any and all tweets about the event with #buildAlong.

So, in summary:

1. Get a nice, neat, tidy PSD together.
2. Send me a JPG of it as per the exact email rules.
3. I’ll announce whose PSD I’ll be building in a blog post.
4. Be around at about 7pm UTC (Dublin, Edinburgh, Lisbon, London) on Friday 4th November to watch along as I code.
5. You will get a HTML/CSS single page template emailed back to you once it’s done.

Right, get emailing me!

Update

While there are loads of you interested in watching this event, no one has sent in a PSD. Not one! Mention this to friends, your boss, your designer, anyone. Without a PSD the build-along can’t run :(

I’ve been toying around with this idea the last few weeks. I’ve decided to do a quick testing-the-water blog post to gauge interest and see whether anyone else would be into the idea. The story goes thus…

A few weeks ago I was building a page for my good friend and awesome chap Nick Payne—the page had been designed by another swell fella, Ian Thomas. We’re all pretty good friends and all excel in different areas, Ian designed Nick’s site and, as designers don’t need to code, I built it. Nick sorted all the back-end and is building it onto JAOSS.

N.B. Ian can and does actually code, but for this project we all wanted a slice of the action so, in this case, he didn’t…

Anyway, I always build static HTML files in my Dropbox public directory as people can have a quick look at it if I need to share it, plus I can test it on a variety of browsers on different devices. I gave Nick the URL early on and told him I was about to get to work…

An hour or so later I got a text from Nick saying that he was loving seeing the progress with every refresh, which I also thought was pretty cool.

Enter my idea… a live build-along!

The idea I’m toying with is that people (it could be pretty much anyone) get in touch (somehow) with PSDs they need building; a PSD that they were going to get their staff in their agency to do, or that they were going to give out to a freelancer, anything, and I will pick one and build it for free on the provision I can build it in my public directory and that people can watch along as I code away.

There are obviously some massive requirements:

• People would actually want to watch me code a page up; I feel I may be being terribly big-headed in assuming people might actually want to watch me code.
• The PSD is all above board, doesn’t break any NDAs etc.
• Whoever gets ‘picked’ doesn’t mind their work being made wholly public from the outset.

The outcomes would be:

• Someone gets a free template (one page) built.
• People who wouldn’t die of boredom get to follow along as I build a page (I seriously think the idea of seeing how someone tackles a build would be really cool, it’d be like watching TV and yelling along: ‘Clear your floats!!!’)

So basically:

1. People submit PSDs.
2. I choose one.
3. I pick an evening to build it.
4. I share the URL on Twitter and in a blog post.
5. People can keep the tab open and keep dipping in-and-out as I build, watching the progress.
6. For people not in the right time-zone I could potentially record the screen.
7. I finish and hand back a fully coded single-page.

Naturally there would be some informal terms and conditions that I’d iron out nearer the time but for now, anyone interested?

Lemme know!
Harry

Have you ever wanted to say something like ‘There are three things to look out for:’ and then follow with a numbered list with the three things in?

I’m pretty sure we all have, and that we’d all normally use an <ol> to get the numbers, right? That’s how you get numbers next to list items after all…

Well the problem here is that the numbering defines an amount, not an order. The order is usually irrelevant in this scenario.

To make more sense I’ve drawn up a small fiddle of examples and the reasoning in each.

Here we can see that, although we want numbers, we don’t always want order.

The trick I’ve started employing is is to have a .numbered class which I can apply to a <ul> to make it mimic the appearance of an ordered list, without semantically carrying the ordered weight. This is how I do it:

ul,
ol{
  margin-bottom:1.5em;
}
li ul,
li ol{
  margin-bottom:0;
}
ul{
  list-style:square outside;
}
ol,
.numbered{
  list-style:decimal outside;
}

There. As simple as that. These are pretty much my default list styles now, and all I’m really doing is making an unordered list with a class of numbered look the same as an <ol>.