I went along to the fifth Barcamp Brighton on the weekend. It was a truly excellent event, hosted in The Skiff, a great coworking space. Alas, a creeping cold meant that I couldn’t stick around for too long, but I made sure to give a presentation before I bailed.
I didn’t prepare any slides. If I had, they would have consisted of screenshots and CSS, so I figured
In reiterating my point about fluid grids being a necessary prerequisite for responsive web design, I tried to take a long-zoom approach and went all the way back to John’s superb A Dao of Web Design article—now ten years old!
The tool problem
I still feel that most designers haven’t yet fully embraced the web as its own medium, choosing instead to treat it along the same lines as print design. Or, as Mark put it his excellent talk on designing grid systems, designing from the canvas in rather than the content out.
Far too early in the design process, a tool such as Photoshop or Fireworks gets opened up and a new file is created with an arbitrary width (960 pixels being the current width du jour). That process lends itself well to creating paintings of websites but it’s not a great first step in creating a living, breathing website. Experiments like Liz’s Evening Edition not withstanding, what I wrote back in 2006 still holds true:
CSS hasn’t revolutionised web design. The reason lies not with the technology (which is revolutionary), but with the designers using it. Most designers have simply swapped the old technology (
fonttags) for the new technology, without fully exploring what’s so completely new.
My point is that responsive web design isn’t something that can be tacked on to the end of an existing workflow. It requires a different mindset, one that considers the medium from the outset. If you’re currently thinking in proportions rather than pixels, the transition to responsive web design will be relatively painless. But if you’re stuck in the world of converting PSDs into web pages, you’re going to have a tough time.
A new approach
At Barcamp Brighton, I encapsulated my thinking by saying:
Instead of thinking in terms of pixel perfection, we should be thinking of proportion perfection.
All of those sites are built in a similar way. First, CSS is used to create the
optimal layout e.g. three columns floated alongside one another. Then media queries are used to over-ride those
width declarations so that the content is linearised.
That’s all well and good but, as someone correctly pointed out during the presentation, what about small-screen devices that don’t support media queries?
That’s an excellent question. The answer requires another shift in perspective. Instead of thinking of the widescreen version as the starting point, why not consider the small screen layout first?
In his presentation at Over The Air, Bryan Rieger advocated this approach for media queries. As he correctly points out—and this is something echoed by PPK—what we’re talking about here is essentially progressive enhancement.
Instead of just using progressive enhancement to throw in some rounded corners, opacity or gradients, we can apply the same thinking to layout: start with the most basic CSS—colours, fonts, etc.—and then apply
widths according to the capabilites of the browser …as determined by media queries.
At this point, you might be wondering if I’m going to mention the elephant in the room. You know: the elephant …from Microsoft …elephant versions 8 and lower.
My first thought was to use conditional comments. All browsers get the same stylesheet but elephantine browsers get an extra one which contains the same
width declarations that are contained in the media queries. But that violates the DRY principle: any time I make a layout change, I would have to remember to make the changes in two different stylesheets. Prem suggested placing an
@import rule within the media query to pull in the same stylesheet that IE is getting via conditional comments …but alas,
@import rules need to come first in a CSS document.
So, for now, users of Internet Explorer visiting adactio.com will just get the linearised content. I may decide to violate the DRY principle and use conditional comments at a later date.
Over the years, I’ve resisted the temptation to do a complete redesign of my site. Instead, I’ve added different designs as options that can be selected from any page on the site. After all, isn’t the whole point of CSS that it’s separated from the structure? Changing the visual appearance shouldn’t necessitate changing the markup; that’s the lesson of the CSS Zen Garden.
So I’ve stubbornly refused to update my markup for almost ten years. But now, what with having written a book on HTML5 and all, I figured I could make a few changes.
The doctype has been updated. Elements that had previously been given IDs are now identified with ARIA landmark roles instead (and referenced in the CSS with attribute selectors). These days, I rarely use IDs for anything other than making document fragments addressable, so it was interesting to see how my past self did things differently.
My past self was also trying to be far too clever with the separation of concerns in the CSS. I was using three different stylesheets for each theme: one for colour, one for typography, and one for layout. In retrospect, this was a bad idea for two reasons:
- I’m increasing the number of HTTP requests.
- While it might be obvious that
font-familydeclarations belong in the typography stylesheet and
background-colordeclarations belong in the colour stylesheet, it’s not nearly so simple to figure out where
paddings should go. Is that layout? Is it typography?
It turns out that a more holistic approach to CSS is far, far easier to work with. It felt good to finally merge those separate CSS files into one.
Oh, there was one more good point raised at the Barcamp Brighton presentation… I had being going on about how assumptions can be dangerous—assuming that the user is visiting your site from a desktop machine, assuming that a large monitor size equates to a large viewport size, assuming that a large browser window means that large bandwidth is available, and so on. Somebody pointed out that, in applying my media queries using pixels, I was making assumptions about equating pixel width to viewable area. An excellent point! For that reason, all the media queries used in the different themes on adactio.com are triggered with
ems rather than pixels.
For the record, here are some useful
em widths that can be used as trigger points:
- 40em =~ 640px
- 50em =~ 800px
- 64em =~ 1024px