Responsive enhancement
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 spoke about media queries. As you may have gathered from my recent entries, this is something I’ve been thinking about a lot lately.
I didn’t prepare any slides. If I had, they would have consisted of screenshots and CSS, so I figured why not just show the actual sites and CSS instead?
It was a fairly rambling, chaotic presentation but it helped me to clarify some ideas. Prem asked if I would reprise the presentation at Async—Brighton’s JavaScript meetup—on October 28th so that will give me a chance to marshall my thoughts.
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 (
tables
andfont
tags) 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.
I’ve written about the problems with our tools before and Stan has crafted the definitive call to arms for A Real Web Design Application so I’ll spare you another rant.
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.
Then I showed a bunch of sites I’ve worked on that are using media queries to adapt to different screen sizes: Huffduffer, Salter Cane, St. Paul’s School and UX London.
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 float
and 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 a way, this is an extension of Luke’s Mobile First exercise — thinking of the mobile experience before building the desktop site.
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 float
s and width
s according to the capabilites of the browser …as determined by media queries.
That’s what I did for the Science Hack Day website and now I’ve decided to take the same approach with adactio.com.
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 float
and 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.
Revisiting adactio.com
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-family
declarations belong in the typography stylesheet andbackground-color
declarations belong in the colour stylesheet, it’s not nearly so simple to figure out wheremargin
s andpadding
s 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 em
s 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