Tags: adaptive



Secret src

There’s been quite a brouhaha over the past couple of days around the subject of standardising responsive images. There are two different matters here: the process and the technical details. I’d like to address both of them.

Ill communication

First of all, there’s a number of very smart developers who feel that they’ve been sidelined by the WHATWG. Tim has put together a timeline of what happened:

  1. Developers got involved in trying to standardize a solution to a common and important problem.
  2. The WHATWG told them to move the discussion to a community group.
  3. The discussion was moved (back in February), a general consenus (not unanimous, but a majority) was reached about the picture element.
  4. Another (partial) solution was proposed directly on the WHATWG list by an Apple employee.
  5. A discussion ensued regarding the two methods, where they overlapped, and how the general opinions of each. The majority of developers favored the picture element and the majority of implementors favored the srcset attribute.
  6. While the discussion was still taking place, and only 5 days after it was originally proposed, the srcset attribute (but not the picture element) was added to the draft.

A few points in that timeline have since been clarified. That second step—“The WHATWG told them to move the discussion to a community group”—turns out to be untrue. Some random person on the WHATWG mailing list (which is open to everyone) suggested forming a Community Group at the W3C. Alas, nobody else on the WHATWG mailing list corrected that suggestion.

Then there’s apparent causality between step 4 and 6. Initially, I also assumed that this was what happened: that Ted had proposed the srcset solution without even being aware of the picture solution that the Community Group had independently come up with it. It turns out that’s not the case. Ted had another email about the picture proposal but he never ended up sending it. In fact, his email about srcset had been sitting in draft for quite a while and he only sent it out when he saw that Hixie was finally collating feedback on responsive images.

So from the outside it looked like there was preferential treatment being given to Ted’s proposal because it came from within the WHATWG. That’s not the case, but it must be said: the fact that srcset was so quickly added to the spec (albeit in a different form) doesn’t look good. It’s easy to understand why the smart folks in the Responsive Images Community Group felt miffed.

But let’s be clear: this is exactly how the WHATWG is supposed to work. Use-cases are evaluated and whatever Hixie thinks is best solution gets put in the spec, regardless of how popular or unpopular it is.

Now, if that sounds abhorrent to you, I completely understand. A dictatorship should cause us to recoil.

That’s where the W3C come in. Their model is completely different. Everything is done by committee there.

Steve Faulkner chimed in on Tim’s post with his take on the two groups:

It seems like the development of HTML has turned full circle, the WHATWG was formed to overthrow the hegemony of the W3C, now the W3C acts as a counter to the hegemony of the WHATWG.

I think he’s right. The W3C keeps the rapid, sometimes anarchic approach of the WHATWG in check. But the opposite is also true. Without the impetus provided by the WHATWG, I’m not sure that the W3C HTML Working Group would ever get anything done. There’s a balance that actually works quite well in practice.

Back to the situation with responsive images…

Unfortunately, it appears to people within the Responsive Images Community Group that all their effort was wasted because their proposed solution was summarily rejected. In actuality all the use-cases they gathered were immensely valuable. But it’s certainly true that the WHATWG didn’t make it clearer how and where developers could best contribute.

Community Groups are a W3C creation. They don’t have anything to do with the WHATWG, who do all their work on their own mailing list, their own wiki and their own IRC channel.

I do think that the W3C Community Groups offer a good place to go bike-shedding on problems. That’s a term that’s usually used derisively but sometimes it’s good to have a good ol’ bike-shedding without clogging up the mailing list for everyone. But it needs to be clear that there’s a big difference between a Community Group and a Working Group.

I wish the WHATWG had done a better job of communicating to newcomers how best to contribute. It would have avoided a lot of the frustrations articulated by Wilto:

Unfortunately, we were laboring under the impression that Community Groups shared a deeper inherent connection with the standards bodies than it actually does.

But in any case, as Doctor Bruce writes at least now there’s a proposed solution for responsive images in HTML: The Living Standard:

I don’t really care which syntax makes the spec, as long as it addresses the majority of use cases and it is usable by authors. I’m just glad we’re discussing the adaptive image problem at all.

So let’s take a look at the technical details.

src code

The Responsive Images Community Group came up with a proposal based off the idea of minting a new element, called say picture, that mimics the behaviour of video

<picture alt="image description">
  <source src="/path/to/image.png" media="(min-width: 600px)">
  <source src="/path/to/otherimage.png" media="(min-width: 800px)">
  <img src="/path/to/image.png" alt="image description">

One of the reasons why a new element was chosen rather than extending the existing img element was due to a misunderstanding. The WHATWG had explained that the parsing of img couldn’t be easily altered. That means that img must remain a self-closing element—any solution that requires a closing /img tag wouldn’t work. Alas, that was taken to mean that extending the img element in any way was off the cards.

The picture proposal has a number of things going for it. Its syntax is easily understandable for authors: if you know media queries, then you know how to use picture. It also has a good fallback for older browsers : a regular img element. This fallback mechanism (and the idea of multiple source elements with media queries) is exactly how the video element is specced.

Unfortunately using media queries on the sources of videos has proven to be very tricky for implementors, so they don’t want to see that pattern repeated.

Another issue with multiple source elements is that parsers must wait until the closing /picture tag before they can even begin to evaluate which image to show. That’s not good for performance.

So the alternate solution, based on Ted’s proposal, extends the img element using a new srcset attribute that takes a comma-separated list of values:

<img alt="image description"
srcset="/path/to/image.png 800w, /path/to/otherimage.png 600w">

Not nearly as pretty, I think you’ll agree. But it is actually nice and compact for the “retina display” use-case:

<img alt="image description" src="/path/to/image.png" srcset="/path/to/otherimage.png 2x">

Just to be clear, that does not mean that otherimage.png is twice the size of image.png (though it could be). What you’re actually declaring is “Use image.png unless the device supports double-pixel density, in which case, use otherimage.png.”

Likewise, when I declare:

srcset="/path/to/image.png 600w 400h"

…it does not mean that image.png is 600 pixels wide by 400 pixels tall. Instead, it means that an action should be taken if the viewport matches those dimensions.

It took me a while to wrap my head around that distinction: I’m used to attributes describing the element they’re attached to, not the viewport.

Now for the really tricky bit: what do those numbers—600w and 400h—mean? Currently the spec is giving conflicting information.

Each image that’s listed in the srcset comma-separated list can have up to three values associated with it: w, h, and x. The x is pretty clear: that’s the pixel density of the device. The w and h values refer to the width and height of the viewport …but it’s not clear if they mean min-width/height or max-width/height.

If I’m taking a “Mobile First” approach to development, then srcset will meet my needs if w and h refer to min-width and min-height.

In this example, I’ll just use w to keep things simple:

<img src="small.png" srcset="medium.png 600w, large.png 800w">

(Expected behaviour: use small.png unless the viewport is wider than 600 pixels, in which case use medium.png unless the viewport is wider than 800 pixels, in which case use large.png).

If, on the other hand, w and h refer to max-width and max-height, I have to take a “Desktop First” approach:

<img src="large.png" srcset="medium.png 800w, small.png 600w">

(Expected behaviour: use large.png unless the viewport is narrower than 800 pixels, in which case use medium.png unless the viewport is narrower than 600 pixels, in which case use small.png).

One of the advantages of media queries is that, because they support both min- and max- width, they can be used in either use-case: “Mobile First” or “Desktop First”.

Because the srcset syntax will support either min- or max- width (but not both), it will therefore favour one case at the expense of the either.

Both use-cases are valid. Personally, I happen to use the “Mobile First” approach, but that doesn’t mean that other developers shouldn’t be able to take a “Desktop First” approach if they want. By the same logic, I don’t much like the idea of srcset forcing me to take a “Desktop First” approach.

My only alternative, if I want to take a “Mobile First” approach, is to duplicate image paths and declare ludicrous breakpoints:

<img src="small.png" srcset="small.png 600w, medium.png 800w, large.png 99999w">

I hope that this part of the spec offers a way out:

for the purposes of this requirement, omitted width descriptors and height descriptors are considered to have the value “Infinity”

I think that means I should be able to write this:

<img src="small.png" srcset="small.png 600w, medium.png 800w, large.png">

It’s all quite confusing and srcset doesn’t have anything approaching the extensibility of media queries, but I hope we can get it to work somehow.

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 AsyncBrighton’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 and font 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 floats and widths 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:

  1. I’m increasing the number of HTTP requests.
  2. While it might be obvious that font-family declarations belong in the typography stylesheet and background-color declarations belong in the colour stylesheet, it’s not nearly so simple to figure out where margins and 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


Adactio — default (1440) Adactio — default (1024) Adactio — default (800) Adactio — default (640) Adactio — default (480)

Tate Modern

Adactio — tatemodern (1440) Adactio — tatemodern (1024) Adactio — tatemodern (800) Adactio — tatemodern (640) Adactio — tatemodern (480)


Adactio — seaside (1440) Adactio — seaside (1024) Adactio — seaside (800) Adactio — seaside (640) Adactio — seaside (480)


Adactio — zeldman (1440) Adactio — zeldman (1024) Adactio — zeldman (800) Adactio — zeldman (640) Adactio — zeldman (480)


Adactio — adactizilla (1440) Adactio — adactizilla (1024) Adactio — adactizilla (800) Adactio — adactizilla (640) Adactio — adactizilla (480)


Adactio — sci-fi (1440) Adactio — sci-fi (1024) Adactio — sci-fi (800) Adactio — sci-fi (640) Adactio — sci-fi (480)


Adactio — renaissance (1440) Adactio — renaissance (1024) Adactio — renaissance (800) Adactio — renaissance (640) Adactio — renaissance (480)


Adactio — hirnlego (1440) Adactio — hirnlego (1024) Adactio — hirnlego (800) Adactio — hirnlego (640) Adactio — hirnlego (480)

Responsive refresh

Another week, another responsive web site.

Two weeks ago, it was St. Paul’s School. Last week, it was Salter Cane. This week, I’ve been working on next year’s UX London site, implementing a nice little design refresh courtesy of Paul.

More pages will be added soon but for now, it’s essentially like a poster for the conference.

Back when I was working on the first UX London site two years ago, I was building it together with Natalie, and I mean literally together: we were pair-programming. Well, I guess programming isn’t quite right for HTML and CSS, but we were pair-writing. It was an excellent experience.

Anyway, Natalie being Natalie, the UX London site was built with rock-solid markup with a flexible layout. All the pieces were in place for a responsive web design so once I was done with the current refresh, I spent a few minutes writing some media queries.

UX London (1440) UX London (1024) UX London (760) UX London (480)

You can see the results for yourself.

A responsive mind

Ethan is a brilliant person. Responsive web design is a brilliant technique. These two facts are related.

As Ethan recently clarified:

A responsive design is composed of three distinct parts:

  1. A flexible grid.
  2. Flexible images. Or more specifically, images that work in a flexible context (whether fluid themselves, or perhaps controlled via overflow).
  3. Media queries. The final layer of a responsive design, media queries optimize the design for different viewing contexts, and that spot-fix bugs that occur at different resolution ranges.

There has been a lot of discussion on that third part—including a superb presentation by Bryan Rieger—but there has been less emphasis on those first two parts. Anyone hoping to take an existing fixed-width rigid design and adapt it for smaller screen widths using media queries is going to be disappointed and frustrated.

I recently had to adapt an existing layout for varying screen widths. Clearleft did some design and development work for St. Paul’s School, where the thoroughly lovely David Smith is a teacher. I didn’t have much to do with that initial work. Cennydd worked on the information architecture, JayBay created the beautiful visual design and Natalie produced the HTML, CSS and JavaScript. But when they asked for some small-screen optimisation, the task fell to me.

It was a breeze. Because Natalie’s markup and CSS was rock-solid, I was able to whip up some alternate layouts in no time. The fact that the site was already using a fluid grid and fluid images was crucial.

The site now goes from a three-column layout (on browsers wider than 800 pixels) to a two-column layout (on browsers between 800 and 640 pixels) to a single column layout (on browsers less than 640 pixels). I spent some time finessing the details but the lion’s share of the work was done in the first hour.

St. Paul's School (1440) St. Paul's School (1024) St. Paul's School (800) St. Paul's School (640) St. Paul's School (480)

Notice that I don’t refer to this as mobile optimisation. This is about user-agents with narrow screens. Now, some of those user-agents will be running on handheld devices (whatever that means, these days) and the site certainly looks good on some mobile devices, such as the iPhone, the iPod Touch, the iPad and Android phones. But it works equally well on desktop or laptop-bound user-agents with narrow screen widths.

Some people have misinterpreted the power of responsive web design as being a claim to the title of silver bullet for the mobile context. That’s never been the case. If your content would benefit from a completely different approach when viewed on the go, and you’ve got the time and budget to create a separate mobile site, then go for it (though you may end up going down the rabbit hole of figuring out which devices qualify as mobile and which of those you can support).

But if you’re building your sites the right way anyway, with fluidity and flexibility baked in from the start, then it’s certainly worth spending a few minutes to bash out a couple of quick media queries to optimise for small-screen devices.

The choice is not between using media queries and creating a dedicated mobile site; the choice is between using media queries and doing nothing at all.

That said, in many situations the content you want to serve up will be the same regardless of context. Take Huffduffer, for example. There’s nothing I want to strip out of the pages when they’re served up to mobile devices.

Huffduffer (1440) Huffduffer (1024) Huffduffer (800) Huffduffer (640) Huffduffer (480)

This harks back to what Luke has been saying with his Mobile First talk at An Event Apart. Instead of beginning with a big ol’ desktop site and asking What can I take away for mobile?, ask instead why all that stuff is clogging up your desktop site to begin with. Just because you’ve given yourself 960 pixels to play with—or whatever arbitrary number is the current fave of fixed-width designs—doesn’t mean that every piece of screen real estate needs to be filled up.

Another complaint levelled at media queries is when they are used to over-ride background-image declarations or to apply display: none to images: Those images are still downloaded by the mobile user! It’s a fair point but I would turn it on its head: why the sudden concern about bandwidth when dealing with the mobile context? Performance should be a priority for all your users, regardless of screen size or user-agent. If a large image can be hidden from mobile users, why is it being served up to other users?

That’s the thing about responsive web design: you can’t just think of it as a sprinkle of pixie dust that can be applied to any site. It requires the right mindset. It requires that sites be built on solid foundations of best practice. If those foundations are in place—a flexible layout, flexible images, optimised performance—then responsive web design can work its magic.

In the case of St. Paul’s School and its sister-site Colet Court, the foundations couldn’t have been better.

The Adoption of Adaptation

I wrote a little while ago about one of the trends I saw emerging at An Event Apart, namely what the mighty Ethan has dubbed Responsive Web Design. With widespread browser support for media queries and the hype around the iPad and iPhone, there’s a perfect storm of interest in adaptive layouts.

Huffduffer and dConstruct were just the start: now Jon and Colly have both updated their personal sites to become beautifully adaptive and responsive to whatever user-agent their visitors are using.

This is true web design—design with a real understanding for the medium. I still maintain that rigidly-constrained graphics tools—i.e. all of them—are an impediment to moving the web forward in this direction. But the bigger impediment is in the mindset of those who still think of hypertext as something fixed and controllable, like a printed page (see also: every attempt at magazine apps on the iPad).

Back in 2006, I wrote about the unpushed envelope:

The ability to alter the presentation of a website without altering its structure should have opened up the floodgates of design creativity.

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 and font tags) for the new technology, without fully exploring what’s so completely new.

It has taken its own sweet time, but I think the sea change might finally be coming. Dave’s CSS Zen Garden and John’s A Dao of Web Design were the harbingers. Now the first pebbles are beginning to trickle down the mountainside of the web, heralding what I hope is an oncoming avalanche of beautiful, responsive, adaptive layouts.

It makes sense that this change is starting on personal sites; places that have always served as playgrounds and sandboxes for experiments that can then be rolled out in a more commercial setting. Steering larger websites down a new route will always be more challenging. Take the new layout changes on Flickr—they are beautiful changes …as long as your browser window is wide enough. I had to expand the browser window on my laptop in order to view everything on the Flickr homepage or else suffer an ignominious crawlbar.

Still, I’m confident that we’ll see the trend for adaptive layouts spread to larger sites. In the same way that Doug’s Wired redesign and Mike’s ESPN redesign proved the potential of CSS, some enterprising designers at a large site—like Flickr—will take up the challenge of leading the way with responsive web design.

Update: Ethan talks about responsive web design on The Big Web Show:

The Big Web Show: Responsive Web Design on Huffduffer