By this I mean that if you want to create extensible and maintainable, flexible and predictable websites, you should really take care to make your CSS selectors as dev-friendly as possible; i.e. short.

Keeping CSS selectors short helps with a lot of things:

• Increases selector efficiency
• Reduces location dependency
• Increases portability
• Reduces chances of selector breakage
• Decreases specificity
• Can make code more forgiving

This is a very vague list, so I’m going to address each in order. You will find that there is a lot of crossover between each point (e.g. reducing location dependency inherently means your selectors are more portable) but I feel they are all points in their own right.

Increases selector efficiency

I have written before about CSS selector efficiency. I’m going to gloss over a lot of the intricacies in this post so for a full background understanding I recommend you read Writing efficient CSS selectors first.

If we ignore actual types of selector (*{} is typically the slowest, depending on how it’s being used, IDs are the fastest followed by classes, descendants are comparably quite slow followed by pseudo-selectors) then in general it is safe to say that shorter selectors are faster.

This stands to reason, if we compare these two selectors:

html body .header .nav{}
.nav{}

There we can see pretty clearly that in the first example, the browser has to look out for four things, the .nav class, then the .header class, then the body element and then, finally, the html element (browsers read selectors right-to-left).

With the second example the browser only needs to look for one thing; the .nav class. The browser has four times less work to do to match that selector. Every time you write a selector try and trim as much losable stuff from it as possible. Instead of ul.nav{} (two checks) write .nav{} (one check). Instead of .nav li a{} (three) write .nav a{} (two).

Now, CSS selector performance is—by-and-large—not something we really need to worry about any more, but that doesn’t mean we should be wasteful. I’m sure none of us would miss a lost £5 but that doesn’t mean we go slipping banknotes into paper shredders… Selector efficiency does exist and you might as well improve it where you very easily can.

Reduces location dependency

By keeping selectors short you are likely to be reducing the amount of descendant (e.g. .sidebar .promo{}) and child (e.g. .sidebar > .promo{}) selectors. By removing these descending types of selectors you are reducing the necessity for an element to live inside another one. Let’s reuse the .sidebar .promo{} example…

By having a selector like .sidebar .promo{} we are saying we want to target any promotional item that lives in an element with the class of .sidebar. This means that we are tied to always using that styling inside a certain element; we have a dependency on location.

By replacing .sidebar .promo{} with something like .secondary-promo{} we can now place the element in question anywhere we wish. In the sidebar—as before—but now also in the footer, or in the header, or after an article.

By reducing descendants we can really reduce dependency and make things a lot more portable…

Increases portability

So now that we’re not tied to locationally dependant selectors, we find that our components are a lot more portable. We can move things a lot more easily because our CSS doesn’t care where a thing lives, it just cares that it exists. Awesome!

Another way to increase portability is to not qualify selectors. A qualified selector is one like ul.nav{} or a.button{} or div.content{}.

Qualified selectors are bad because they reduce efficiency (more checks than we really need) but also because they tie us to specific elements. We can’t now use that .button class on an <input> or a <button>, for example. We can’t apply .nav to an <ol> to make a breadcrumb.

Selectors should be element-agnostic. Your CSS shouldn’t care what element you’re wanting to apply styling to.

Another way to make selectors more portable is to drop elements altogether. Take this, for example:

/* Base widget styling */
.widget{}

/* Style up widget titles */
.widget > h2{}

Here we have a troublesome selector; what if that <h2> needs to become a <h3>? What if we need to add another, non-titling <h2> as a child of .widget? We’ve made ourselves a very rigid and unportable selector here. Instead we should have:

/* Base widget styling */
.widget{}

/* Style up widget titles */
.widget-title{}

Now we can apply .widget-title to any element—let’s say a <h4>—and can now also have any number of unclassed <h4>s in the widget without them adopting any title styling. Ossom!

Reduces chances of selector breakage

The longer a selector is, the more things the browser has to satisfy before it can match it. The more checks there are then—naturally—the more chance there is for something to go wrong.

A (very exaggerated) selector like body > div:nth-of-type(2) > article:first-child > p:first-child{}—borrowed from my talk Breaking Good Habits—has ten checks; ten things that must be satisfied in order for the browser to make that match.

All that needs to happen is the location of the div:nth-of-type(2) to change or the p:first-child to become a blockquote or the article:first-child to no longer be a child of the div:nth-of-type(2) or any manner of things before that selector will break. Simply replacing that with a class of .intro{} means that there is only one thing that could possibly break, and the chances of that happening are pretty much zero (you’d have to explicitly delete the class from your HTML to prevent a match).

Shorter selectors mean there is statistically less chance for things to go wrong.

Decreases specificity

This is the big one! This is where it really matters!

Longer selectors have a higher specificity. Specificity is a nightmare and you should keep specificity as low as possible all of the time. We already know that we do not use IDs in CSS but a chain of selectors are often just as bad (though not quite).

A selector like .widget > h2{} has a higher specificity (as well as the other problems we discussed) than a selector like .widget-title{}.

.nav li a{} has a higher specificity than .nav a (and is also less efficient). Reducing selector length reduces selector specificity and that is very important. High specificity leads to self-induced specificity battles that can only be won by making subsequent selectors more specific (or using !important, shame on you). This is a terrible thing. The easiest way to reduce specificity (after dropping IDs from your CSS completely) is to keep your selectors short.

Can make code more forgiving

This is a very specific but very decent example of how short selectors can make code more forgiving. However, I will warn you, you can argue two sides of what I’m about to tell you; you can argue that it makes your code a lot more flexible and can gracefully handle breakages or you could argue that it allows breakages in the first place by being too lenient. Anyway, here’s a true story…

In working on a pretty huge project at Sky I stuck to my own rules and coded a (vertical) nav bar CSS like so:

.nav{ /* Nav styles */ }

/* Note NO .nav li styles as this was a vertically stacking nav. */

.nav a{ display:block; /* More styles */ }

Now, there was a CMS error which went undetected where the markup getting spat out was:

<ul class=nav>
    <a href=#></a>
    <a href=#></a>
    <a href=#></a>
    <a href=#></a>
</ul>

Spot the problem? No <li>s! This is really not cool but, as I had used .nav a{} instead of .nav li a{} nothing broke. My code was a lot more forgiving than if I’d had that third check in there.

Now, this doesn’t make the markup right, and it does actually allow poorer markup than a more verbose selector, but you can see how the CSS was very forgiving of a markup error.

Now I said you could argue both sides here, a more verbose selector means that we’d have spotted the CMS error immediately as no styles would have hit the <a>s. But! In the same breath, our CSS was flexible enough to be okay with that. Make of it what you will, because I too am sat on the fence and a little disappointed that the error wasn’t spotted, but here is a very specific example of how shorter selectors can lead to more forgiving CSS.

Final word

I did mention that this is a rule I’ve applied to larger sites but, honestly, you should apply this everywhere. The things we’ve discussed tend to really come into their own (and their absence painfully aware) on larger builds, but they will definitely, definitely help you on builds of all sizes; small or large.

So, by using more classes and less descendants, keeping selectors short and portable, keeping selectors element-agnostic and generally considering maintenance and chance-of-change when writing our CSS, we can really easily improve the quality of our code infinitely. We can make things more efficient, more forgiving, more flexible and more reusable just by revisiting one of the most simple and fundamental aspects of CSS; our selectors.

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?

Unfortunately, a number of the HN community didn’t take so well to my points so I’ve decided to publish a full response, as opposed to the disjointed and frankly unprofessional comment discussion that was emerging.

One user in particular took exception to a lot of my advice and it is his issues I shall address most directly. This isn’t a vendetta at all, more my trying to answer his and others’ concerns at large. He offered a pretty 1:1 comeback to a lot of my points so I shall try to maintain a similar format here.

I may paraphrase a lot here so I urge you, please, read the original thread. I apologise and regret and instances in which I come across as rude and/or unprofessional; I acted on impulse rather than rationally, as I should have done.

I said:

”For each level of markup nesting, try and indent your CSS to match.”

He said:

“Nope.”

Indenting CSS to mirror your markup structure can be very useful for a number of reasons, chief among which is the ability to see at a glance how the listed CSS selectors should be used in HTML. For example, when building a carousel, I often find myself with CSS selectors like:

.carousel{}
.panes{}
.pane{}
.slide-image{}
.slide-title{}

As these selectors are only one class deep it is difficult to see at a glance how they might map to my HTML. One solution might be to write my CSS like so:

.carousel{}
.carousel .panes{}
.carousel .panes .pane{}
.carousel .panes .pane .slide-image{}
.carousel .panes .pane .slide-title{}

But of course you don’t need me to tell you how nasty that is…

Instead, I prefer a structure more like:

.carousel{}
    .panes{}
        .pane{}
            .slide-image{}
            .slide-title{}

Here my selectors are still nice and short but I can still see how they map to my HTML structure. I find this really useful to see at a glance how these rules relate to one another.

If you don’t like this, or won’t find it useful, that’s cool! Just don’t use it.

I said:

“Also write vendor prefixed CSS so that colons all line up”

He said:

“Nope”

I really have no idea why you wouldn’t do this one. It’s often been proposed that we should write vendor prefixed CSS thus:

-webkit-border-radius:4px;
   -moz-border-radius:4px;
        border-radius:4px;

This means all our values—the bits that matter the most—are lined up to a) scan quickly and b) edit at once with columnal typing (in text editors which support it). This, to me, is a no-brainer and a very quick-win.

I said:

“Instead of building dozens of unique components, try and spot repeated design patterns abstract them; build these skeletons as base ‘objects’ and then peg classes onto these to extend their styling for more unique circumstances.”

He said:

[Not unless you are a big website like Facebook]

It doesn’t matter if you are working on the next Facebook or for some guy from the pub, if you can build a website from several repeated components you should. From a performance, consistency, maintainability and sheer sensibility point of view, don’t solve the same problem a dozen times when you can solve it once with an abstraction.

Best practices are best practices, the size of a project is irrelevant.

I said:

“All components should be left totally free of widths; your components should always remain fluid and their widths should be governed by a grid system.”

He said:

“Nope. Again, grid systems are something that should be used on a case-by-case basis, according to the nature of the site you’re building.”

Here I made something of a mistake; when I say grid system what I actually mean is any means of abstracting your layout into its own layer.

If this is a grid system then this is simple; a grid system handles your layout and your components fill it.

If you are not using a grid system then wrapper and parent elements should handle layout and the components should still say fluid. As I said on Twitter just three days prior to this:

“Box-model properties are the most fragile and unpredictable and thus should be avoided wherever you can. Leave layout to wrappers/parents…” (#)

And:

“When sites break it‘s usually because of layout—the less layout stuff we declare the less chance it has to break. Abstract layout to grids!” (#)

Whether using a grid system or not, your components should not carry dimensions. Think of a page like a set of shelves; you set up your shelving units (grid system (or similar)) and then populate them with things (components). If you didn’t have the shelves erected then the components would be supporting themselves, holding themselves up; this makes moving or changing them very volatile.

Abstract your layout to wrappers, parents or grid systems, always.

I said:

“Heavily location-based selectors are bad for a number of reasons.”

He said:

“Nope. What you’re arguing against is a rule that has a high degree of specificity…”

I’m not; I’m talking about location based styling. As soon as an elements begins to rely on its parent, and their parent, and their parent’s parent then you are doing it wrong. Your styles should never rely too heavily on where they live as this makes them incredibly unportable.

Putting classes on the elements you wish to affect rather than drilling down to them via the DOM tree is a lot better in terms of portability in that you don’t have to rely on a location in order to set styles. This one really is a no-brainer for me…

I said:

“An over-qualified selector is one like div.promo”

He said:

[This is actually a good idea unless you want a class to be applicable to any element]

Erm, yes please! Ideally classes are applicable to any element; classes should be element-agnostic. The ability to apply them to any element we wish is exactly what we want.

Why would you ever, ever write div.promo{} in your stylesheet if that could be left at .promo{}?! Why would you ever limit yourself to only being able to use a class on one type of element when you could leave the leading type selector off and have an element-agnostic rule?

This is another no-brainer to me. Don’t tie yourself to things when you really just don’t need to. I think we can all agree that .promo{} is a lot more (re)usable than div.promo{}. By tying an element to any class you are the only thing that will hinder you going forward; you are preemptively closing a lot of doors on yourself…

I said:

“Do not use IDs in CSS at all.”

He said:

“NOPE NOPE NOPE NOPE NOPE. Understand specificity rules. Write good selectors. Don’t outright ban IDs just because you’re not careful enough to write clean CSS.”

I’m pretty sure no CSS developer has ever said ‘I wish I’d used an ID here instead of a class.’

IDs work, sure, but they are way too specific. It doesn’t matter how good a developer you are, you cannot change the fact that an ID is massively more specific than a class.

I would genuinely love to see an elegant solution to this that doesn’t use a class over an ID. (There isn’t one.)

There is literally no reason why, from a purely CSS point of view, that an ID is better than a class. An ID is impossible to reuse (whether you want to or not) and they have a way-over-the-top specificity.

Anything you can do with an ID can be done with a class, but with none of the drawbacks. IDs will only ever trip you up because you can never reuse them and they will trump your class-based-selectors by quite an order of magnitude.

Classes; all the bits you love about IDs with none of the bits that are like IDs.

To me, another no-brainer.

I said:

“As a general rule, all layout and box-model rules can and will work without an IE stylesheet if you refactor and rework your CSS.”

He said:

“Hahahahahahahahahhaa”

I was the sole CSS developer on Sky Bet. This project (as a whole) has taken over a year for the whole team involved (and almost a year of my dev time).

To support IE7+ I used all of zero IE stylesheets. Not one. A project which took me almost a year did not require one single IE stylesheet. It is doable, it should be done.

I haven’t written an IE stylesheet in all of my professional career. I started working when I was 18 so that makes three years; I haven’t written an IE stylesheet in over three years. It’s not that hard, seriously.

To just laugh off such a statement seemed a little odd, but seriously, if you invest enough time and take enough care, you will not need an IE stylesheet.

Like I said in the documents’s README, you can disregard the advice if you wish, but make sure you fully understand it before shunning it completely.

Nicole Sullivan—who totally rocks—has laid a lot of new foundations for us in her work on OOCSS and her ‘unconventional’ but absolutely spot-on approach to building websites. Gems like the media object have seriously changed how I build websites and, if you take the time to study it for yourself, I think it might just do the same for you as well.

Double-stranded heading hierarchy

Another absolutely stellar nugget of wisdom she’s given us is what I call double-stranded heading hierarchy. This is the practice of defining a class every time you define a heading in CSS.

For example, if—for whatever reason—we want our h2s in our sidebar to be the same size as a h1, and the h4s in our footer to be the same size as a h3, we might have had some code like this:

<div class=content>
  <h1>Lorem</h1>
</div>

<div class=sub-content>
  <h2>Lorem</h2>
</div>

<div class=footer>
  <h4>Lorem</h4>
</div>

h1,
.sub-content h2{ [font styles] }
h2{ [font styles] }
h3,
.footer h4{ [font styles] }
h4{ [font styles] }
h5{ [font styles] }
h6{ [font styles] }

But now we’d have:

<div class=content>
  <h1>Lorem</h1>
</div>

<div class=sub-content>
  <h2 class=h1>Lorem</h2>
</div>

<div class=footer>
  <h4 class=h3>Lorem</h4>
</div>

h1,.h1{ [font styles] }
h2,.h2{ [font styles] }
h3,.h3{ [font styles] }
h4,.h4{ [font styles] }
h5,.h5{ [font styles] }
h6,.h6{ [font styles] }

As you can see, the former is far more arbitrary and those lists of selectors can soon become unwieldy, especially over a larger project. By assigning a class along with each heading style we now have those styles attached to a very flexible selector that can be moved anywhere, rather than to a very specific and non-movable one.

Now, I’m not such a fan of the .hN notation, I much prefer a solution that I believe to have been suggested by Mr Jeremy Keith, and that is to use abstract classes made up of the first six letters of the Greek alphabet, thus:

h1,.alpha   { [font styles] }
h2,.beta    { [font styles] }
h3,.gamma   { [font styles] }
h4,.delta   { [font styles] }
h5,.epsilon { [font styles] }
h6,.zeta    { [font styles] }

Which now gives us:

<div class=content>
  <h1>Lorem</h1>
</div>

<div class=sub-content>
  <h2 class=alpha>Lorem</h2>
</div>

<div class=footer>
  <h4 class=gamma>Lorem</h4>
</div>

Neat, huh?

So now .alpha can carry the style information of a h1 wherever you wish; it doesn’t depend on location or a type of element. A double-stranded heading hierarchy; lovely.

Extending this?

Okay, so now we have our heading styles all nice and portable we’ve won most of the battle. I’ve been using this method for months now and I love it. My CSS is so much more efficient, more portable, more powerful, I can build faster, I’m not repeating font styles over and over, but what next?

The other night whilst working on faavorite with Nick I came up with a full on font-sizing micro-framework.

The problems I found I had with font-sizing on any site include (but are not limited to):

• Repetition of font-size, line-height etc declarations.
• Overly-specific and/or location-dependent selectors (e.g. .sidebar h2{}).
• Arbitrary font sizes could and did creep into my CSS.
• When using rem with px fallbacks, there is a lot to type!

And a few important things to remember:

• Font sizes, like colour palettes, should be limited, preset and non-arbitrary.
• Vertical rhythm is important and easy.
• DRY code is important for both efficiency and maintainability.
• It’s important to save yourself as much time as possible.
• Classes are neither semantic or insemantic.

With this in mind, I decided that I wanted to use font-sizing much like a grid system; define it once in the stylesheet and just constantly reuse it.

Preset font sizes

Like colour palettes are, font sizes should be strict, predefined and intentional. From both a code and design point of view, you shouldn’t deviate from your scale—you shouldn’t really ever need to and doing so will just make code harder to work with.

Presetting your font sizes is pretty easy; typically you might have requirements for:

• Normal body copy
• Headings 1–6
• Small print
• A few other sizes for larger-than-normal headings etc.

Setting the base font size is simple, just pop it on the html and everything will inherit it, paragraphs, lists, tables, you name it.

For your headings you define a series of hN and its corresponding Greek letter class, e.g. h1,.alpha{}.

Non-standard font-sizing

You ever had that need to turn a design up to 11? When you have a masthead promo and even a h1 ain’t big enough? I think we all have…

It’s tempting to create a new, unique selector to cater for this new requirement, perhaps something like:

.masthead h1{ font-size:5em; }

And whilst this will work, you’ll only ever get that 5em goodness if you use specifically a h1 that is specifically in a .masthead. This isn’t very reusable at all. Sadface.

To combat this, I decided to create some new abstract classes, this time borrowing SI prefixes. Now we have the h1,.alpha{} through to h6,.zeta{} that we did before, but as well as those we have:

.giga{ [font styles] }
.mega{ [font styles] }
.kilo{ [font styles] }

These classes are the ones above h1 and are the seldom used ones that make stuff massive!

Going the other way?

Okay, so far we’ve worked with body copy to headings to beyond; what about small print? Well I opted to use:

small,.omega.milli{ [font styles] }

small has been redefined in HTML5 so that’s an element we can use again freely and .omega is simply the last letter in the Greek alphabet.

Addendum

That there genius and awesome chap Tom Hudson suggested I use .milli for this as it goes below the regular scale. So, anything on the normal scale is Greek letters, anything off the scale (above or below) is SI prefixes.

Vertical rhythm

To maintain vertical rhythm we need two key ingredients; consistent line heights and consistent bottom margins. We need a magic number. This number is typically defined by the line height of your body copy, so if you have html{ font-size:16px; line-height:1.5; } then your magic number is 16 x 1.5 = 24.

Now you know that all your line heights and margin bottoms have to be a multiple of 24px.

Bringing it together

It really is imperative to take a look at an actual example of all the above brought together in order to fully ‘get’ it. I made this jsFiddle demo of just CSS; you can add HTML and tinker with it yourselves, combining elements with classes to create double stranded, portable font sizing framework stuff!

Where does that leave us?

We now have a self-contained font-sizing framework which should hopefully mean we never need to define another font-size declaration again! We can manage our brand specific type rules from one place, we can build stuff faster, we can build faster stuff, we can keep our code DRYer, we can keep our styling a lot more consistent, we can keep styling location independent and we can make far reaching changes in one fell-swoop!

Feel free to take the code and modify or improve it.

Also please note that I am not suggesting we all use these specific classes; experiment, find your own, see what you’re comfortable with and report back!

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

These methods seem to have all happened sequentially, with us each time dropping the last. I’ve decided, though, that the best builds use aspects of all previous methods; fixed, elastic and fluid.

Using percentages…

Let’s forget responsive design for a second. Responsive design is a three-tiered approach but here we’re only interested in fluid layouts (N.B. not even necessarily fluid grids). A fluid layout, as you all know, is one that is size-agnostic; it acts like a liquid, occupying a constant percentage of a varying space.

Now, fluid grids are a little tricky as they’re based around full grid systems. Luckily I’ve created a simple fluid grid calculator to work these behemoths out, but in more simple terms it’s remarkably easy to set a fluid layout even if that was never the intention.

If your designer sends you a two-column design then all you need to do is work out not how big the respective columns are, but instead work out how much bigger one is than the other. That is to say; stop thinking ‘this content area is 600px and the sidebar is 300px’ and start thinking ‘this content area is twice as big as the sidebar’. Percentages work well whether you’re going responsive or not!

Design is about proportions, not absolutes, and in ignoring actual pixel measurements in favour of relative ones you can ensure that designs are not tethered to numbers, but to proportions.

So the next PSD you get sent that is not meant to be responsive, just try this method out and at least make it fluid. If your sidebar is 220px wide and your content area is 640px then take that as meaning ‘the content area is 2.909 times bigger than the sidebar’.

…or using nothing at all

Even better than using percentages is to use no measurement at all. All components you build (navs, tables, figures, thumbnail galleries, banners, you name it) should never have widths (and never ever have heights) applied to them. They should be constrained only by their parents.

An element without measurements is inherently fluid, but in the best possible way; it will work wherever you put it. Ironically, the most important takeaway from this—an article about setting measurements—is simply ‘don’t’. Every time you can avoid setting a measurement, you should.

Using ems

Ems are an old favourite. They’re great for setting type, and with ems it’s all about the type.

As I outline in the next section, I don’t actually set font-sizes in ems; I use rems which is essentially ems-with-benefits. What I do set in ems is things to do with type; margin-bottoms on paragraphs, lists, headings and the like; paddings on buttons, nav links and promos and other such measurements; borders on promos etc.

What this does is ensure that the ‘feel’ of the design is maintained no matter how far a user wishes to scale their text.

Let’s take an example. A designer has made a PSD with a nav in it. The nav links are blocks with a font-size of 12px (0.75em) and a padding of 5px, thus.

Now, as I stated previously, a lot of design isn’t about numbers, it’s about proportions. It’s not about 12px and 5px looking best here, it’s about a link looks best when its padding is just under half its own font-size.

It can be a confusing way of looking at things at first, but once you realise that the 12 and 5 are actually totally irrelevant here and that it’s about their relation to one another, you should soon get the hang of things.

Let’s assume the user doubles their font-size, now you have a link that is 24px in size but still has a padding of 5px. That’s going to look very cramped. This is why we need to set paddings on text in ems, so that they track the font-size. In this case 5px as an em unit of 12px is 0.417, so now our code looks like this. Try scaling up these two examples up and see how the second looks a lot nicer when the padding scales too.

So, whenever you are setting a measurement because it looks good when set against nearby type (think borders, paddings, margins etc) try and forget the absolutes and begin thinking ‘this padding needs to be just under half of whatever the font-size needs to be’.

Not convinced that users scale their text all that much? Well I have no data but I love this thought provoking analogy from @5minuteargument:

“I’m going to start using TV volume as a CSS font analogy: not everyone is listening to your programme at the same volume…”

Please note that when I refer to scaling I don’t mean the browser’s Ctrl+[+/-] scaling/zooming, I mean a user stylesheet or design alteration that changes the base font-size of the document.

Line-heights

There are several ways of setting line-heights. A general rule of thumb is to never set them in pixels as this, as discussed above, won’t track your font-size. In this case you’d set them in ems or percentages, so that you never end up with ‘a font-size of 12px and a line height of 18px’, you’d get ‘text whose line-height is 1.5 times its font-size’.

However, even better than using ems, you just set them unitless. Work out the em value, but drop the em from the value, so line-height:1.5em; would just be line-height:1.5;. Eric Meyer explains this nicely over on his site.

To work out unitless line-heights is simple. Use the following equation: the line-height I want ÷ the font-size I have. Want a 20px heading to have a 30px line-height? 30 ÷ 20 = 1.5. A 12px button to have a 24px line-height? 24 ÷ 12 = 2.

Using rems

Despite my initial thoughts, I have now started setting type in rems (with a pixel fallback).

This gives us two things, firstly we have what I call ‘progressive accessibility’ in that it brings the accessibility benefits of ems but only in more advanced browsers.

Secondly, and more importantly, it gives us the confidence of pixels plus the scaling properties of ems. This is ridiculously cool. What this means is that we avoid the annoying compounding issues that ems can give us (a small in a smaller-than-body-copy promo springs to mind) but we can also keep their feature of scalability; we can alter the (font-)size of an entire document based on a parent rather than having to redeclare each individual elements’ font-size over and over. It really is the best of both worlds.

Take this example. Try changing the html’s font-size to 2em, does the page scale up as a whole? Nope. Try this one. See how just changing the html element’s font-size will make your entire page act accordingly. This is something that pixels can’t give us…

Interestingly, I also set margin-bottom in rems so as to always maintain a consistent vertical rhythm around my magic number.

Using pixels

I’ve said before today that the pixel’s day is numbered in the web design world. Most of my work involves ems, rems, percentages or nothing at all. The only time I ever really use pixels is if I have a known and fixed dimension to work to; nearly all the time this is images and icons.

Most pixel based measurements pertain to laying out fixed-size images like avatars or sprited elements who require fixed-size background images applying to them. Nearly everything else is best suited to proportional sizing with ems or to non-sizing with just being left fully fluid.

There really isn’t much work left for the old pixel in 2011.

An example

A fairly decent pre-existing example of the techniques discussed would be my hry.rbrts.me hub-site.

If you open that page and fire up your inspector you should see that:

Percentages

The body and articles all have their structure set in percentages.

Nothing

The social icons component is free of dimensions, it’s fully fluid and will always occupy its parent, wherever you put it.

Ems

The indentations of uls, ols and dds are all set in ems so that they will scale with the lists’ font-size. The gaps between sections are also set in ems so that if the font-size ever increases, so will the space around sections of text.

Line-heights

These are all set unitlessly (except the tagline which needs to line up with the logo).

Rems

Type styles are all set in rems to allow us scaling with control.

Pixels

Only the social media icons and the logo, which are fixed in size before we even start thinking about CSS, are set in pixels.

If you’d prefer, you can poke through the nicely formatted and commented CSS on GitHub.

Key points

The key things to take away from this article are:

• Set structure in percentages. This includes content areas, sidebars etc.
• Set type in rems with a pixel fallback for older browsers. This gives us a great amount of control with added scalability.
• Set type-related items in ems so that paddings et al scale with the font-size.
• Set line-heights in relative units. Or, even better, with no units at all.
• Don’t set measurements on components at all. They should remain fully fluid and ‘just work’ wherever you drop them.

So there are a few tips and guidelines on sizing UIs and designs in 2011. We have a whole host of brilliant methods at our disposal and we can just cherry-pick them whatever they’re best suited to.

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!