I’ve always resisted using class names such as .one-col, .two-col etc. to control layout, mainly through habit but partly because there’s a residual fear of committing a semantic sin.

Snook’s article showed me that the opposite is true. If you don’t use presentational classes to control presentation then your CSS and HTML‘s meaning are intertwined and will become more difficult to manage.

An example: The content area

Take this common article page structure:

A typical content area and sidebar layout

Which I’d normally markup like this:

<div id="content"> ... </div> <aside class="sidebar"> ... </aside> 

And style like this:

#content {float: left; width: 65%; margin-right: 5%;} .sidebar {float: left; width: 30%;} 

That’s fine, until you need to style a #content area with different dimensions. Let’s say you want to build a home page with a big splash image:

A typical home page structure

The mark up’s easy:

<div id="content"> <img> </div> 

But the style poses a problem. Our initial #content area was floated, given a right margin and a width of 65% of its container. But we want the home page #content area to extend across 100% of its container, and we don’t need the right margin.

It is possible to retain our markup and play around with specificity to make sure the home page is styled how we want it:

.home #content {float: auto; width: 100%; margin-right: 0;} 

But that’s inefficient and difficult to manage. The CSS has to be written in a definite order and what if we need other #content layouts?

We’ve run into this problem because we’ve used CSS to style a semantic id. In other words, we haven’t really separated our content from its appearance.

The fix: Embrace ‘presentational’ class names

We need to use classes according to their functions. Snook uses the phrase “limiting the depth of applicability”, which means even our presentational CSS classes should be limited to specific jobs within their overall function.

In our example we could use this markup on our article page:

<div id="content" class="two-col"> ... </div> <aside class="sidebar one-col last"> ... </aside> 

And this markup on our home page:

<div id="content" class="three-col last"> <img> </div> 

And this CSS:

.one-col {width: 30%; margin-right: 5%;}; .two-col {width: 65%; margin-right: 5%;} .three-col {width: 100%;} .last {margin-right: 0;} 

To some people (such as me) this seems counter–intuitive. But it appears to be the most efficient, manageable way to write markup and CSS.

There’s one argument that’s central to me, and I’ve been making it for years. As Bruce puts it:

…sites should be minimal, functional, with everything designed to help the user complete a task, and then go. But that doesn’t mean that you need to make a separate mobile site from your normal site. If your normal site isn’t minimal, functional, with everything designed to help the user complete a task, it’s time to rethink your whole site. The Pastry Box Project.

Really wide desktop monitors are way too big for text. They’re great for images, but the building block of written communication – the humble paragraph – only needs around 500 pixels of your average monitor at 1em/16 pixels (if you’re serving up smaller paragraph text than that you’re committing another cardinal sin).

The original, 2008, one column Leon Paternoster

You can up your font size a tad to use up some of that space, but go too far and it’s like punching your reader in both eyes. What to do with those extra 700 pixels?

Filler is the number one reason websites fail to fulfil their most basic function; namely, to enable visitors to perform a task as efficiently as possible. Build for mobile first and your ‘proper’ website will benefit.

Firstly, you can view the latest development version to get an idea of what it’ll look like and how it will work.

Next: Scherzo 3 will cost. I’m thinking of charging £10–15 and various support options.

The only things that need finishing (I think) are:

• making it translation ready
• navigation dropdowns at widescreen resolution

I may add some other bits and pieces.

Progress is slow because I moved house this month. Moving house is not fun. Never move.

Any questions, just leave them in the comments.

Easier said than done, perhaps. Think of all the exciting things you could do to a link to make it look like an advert:

• make an enlarged click area. It’s a good thing if we can wrap block level elements in anchors because it makes for nice, big target areas. But if our links look like adverts it defeats the purpose.
• use bright colours
• use decorative images
• make your links not look like links.

These aren’t hard and fast rules – context is everything – but you see mistakes everywhere. Take the HSBC home page:

A link to an ISA product. The huge click area and oblique image suggest an advert.

More obscure images and links that aren't underlined.

I’m willing to bet that the splash image and the three links beneath it get very little action. If you’re looking for a mortgage or an ISA you’ll head for the navigation menu rather than the picture of the vase and the armchair.

Finding out about savings and mortgages are common user tasks on a banking website. The products need clear navigation, not advertising.

The stream. A mix of short and long posts that's regularly updated.

• the simple layout means I can get to lots of news quickly. The main feature is a vertical list of stories that’s easy to scan.
• a stream of news updates where content is pushed out at a rate of about 10–20 posts an hour (more when a big story breaks). The blog format allows the editors to publish traditional, long form articles as well as shorter, 50–100 word pieces (similar to a Tumblog or WordPress asides)
• a Twitter–like update notification system. This is really good as it introduces a sense of urgency, especially when a big news story breaks (yesterday’s budget, for example)
• articles grouped by stories rather than extensive taxonomies, which results in
• simple navigation.

This feels modern – something dynamic that’s been built for the web rather than grudgingly shifted over from another medium. It makes other news sites seem static and rooted in a print–based past. And, most of all, it’s been built on what users, rather than editors, want.

It also shows that the Tumblr ‘make it easy to publish’ format is fine, as long as the editorial is of a high quality.

Making your site work on a range of mobile devices is the new accessibility battleground. What’s a fair and realistic approach? Do we assume everyone is using a relatively capable device?

And if you’re serving the same HTML, javascript, CSS and images to each and every phone, tablet and desktop will you have to compromise your desktop site?

1. pare down the blog elements to the basics of what the reader wants, namely:
   • a navigation menu with an about page and a link to the Scherzo theme page
   • one column
   • links to next and previous posts
   • search box
   • Twitter and RSS
2. get an idea about a layout, graphic, typeface etc. and try it out in a new design
3. get bored of this design
4. goto 1

I’ve rebuilt my site, tweaked menus, removed menus, added archive pages, removed category and tag links, added category and tag links and noted the corresponding visitor behaviour countless times. I know what my blog (and most blogs) need to the nth degree.

That’s why messing around with your own site on a regular basis is a good thing. Not only do you get to try out an idea that’d be rejected in the real world (like setting body copy to 20 pixels in 2008), but you get to know how to make something really work.

It’s worth bearing in mind that display: none still has its uses, though. Recently I’ve been working on a mobile navigation menu which is hidden from wide screen users via a media query, and a widescreen navigation menu that’s hidden in the base stylesheet. Up til now, I’ve been using the clip technique to hide these menus.

This looks fine, but it was causing problems for my screen reader navigation menu, which would dutifully read both menus (or rather, I was viewing the page sans CSS and seeing both menus). I was bodging round this by adding headings to both menus: Quick links for the mobile menu and Site navigation for the widescreen menu.

This resulted in a rather long menu. The solution (I think) is to head back to the old practice of using display: none to hide the menus from the relevant screens, so that screen readers would only read the shortened menu. I could then hide another link to a full menu displayed at the bottom of the page using the clip technique.

It’s also worth nothing that an unstyled browser page doesn’t necessarily relate to a  screen reader page. (As Florent explains below.)

What is it with designers and the physical form of books?

Take A Craft Of Consequences: Reader, Writer And Emotional Design. Note the hushed tones, pseudo–scientific language and camp imperatives (must be pieced together indeed.)

As in so many of these articles, the author affords an absurd degree of importance to the role of design in conveying the meaning of a text:

When a visual component accurately represents the ideas of the writer, it becomes a source of emotional information. This aids in the transferral [sic] of ideas, and promotes and persuades the reader that the content is worthy of their precious time.

So the next time you’re debating whether to read Anna Karenina or not, make sure you check out the cover, typeface and weight of the paper. You might even want to test the aroma.

An OK cover, serif font and a wonderful book that doesn't need to be sold by the design.

The truth is that the printed book is an essentially democratic, mass market medium. Movable type allowed writers to communicate ideas to millions of people. Beautiful, hand–written manuscripts were the reserve of rich people and monks.

(Possibly useless fact: the 19th century London émigré communist scene boasted many typesetters, and The Communist Manifesto came with a brand new gothic typeface.)

Yes, the typesetter’s role is important. Without good design and typography the text is difficult to read. Books shouldn’t fall apart after one reading.

But the designer’s main job is to honour the text and get out of the way of the author’s words. It’s a skill, perhaps even an art form, but it’s absolutely secondary to the meaning of the text. It’s the author’s language that aids and forms the meaning of the content, not the designer’s efforts.

So the best textual design is both readable and interchangeable. Take the Penguin Classics range:

Completely different books but the same design.

The design tells us about the publisher rather than the text itself. Even better, Penguin’s Swiss era:

A plain cover and Helvetica: silent design

In fact you could argue that this silent design reaches its apogee with the e–reader, when the text has become completely decoupled from its container.

Of course , there’ll always be a place for pleasing literary objets (coffee table books, if you like). But good book design is fundamentally silent. And long may it remain so.

So I was actually surprised to come across this impassioned article on developers building websites for Webkit only (the rendering engine behind Safari and Android), and the W3C’s proposal to adopt the -webkit- prefix as a de facto standard. Surprised because it strikes me as absurd that anyone would develop something on the web that only works for one browser.

After all, the whole idea of the web is that it’s accessible to anyone, regardless of whether they can afford an iPhone or Android smartphone. The nuts and bolts of the web are built on this idea: HTML and CSS are free, easy to learn, easy to distribute, easy to render and independent of corporate influence.

Maybe I’m old. I can remember the browser wars – a time when websites would only work in Internet Explorer. Banking websites would make visitors upgrade from Firefox to IE6. Can you imagine that now?

Graceful degradation is absolutely fine. But it’s frankly depressing that people are building websites that only work on certain devices, regardless of how trendy they are, or whether they’re made by Microsoft, Google or Apple. And none of these companies should control HTML and CSS standards.