by Flo Preynat

Last time I talked about responsive images, I did mention I was due to go to the responsive images meetup in Paris, and as the long-awaited event happened a couple of days ago, I thought it would be nice to write a quick recap for the folks unable to make it.

Side note

Before we get to the the nitty gritty, let me start this blog post with a quick line on the venue. The meetup took place in Mozilla’s Paris headquarters, a superb office located boulevard Montmartre, in Paris’ 9th arrondissement. What a place this is! Two snaps for your eyes.

Mozilla really know how to welcome guests. Just saying.

High Hopes

Having received a teasing email from Yoav a couple of days prior to the get-together, and seen a number of known representatives from Apple, Google, Mozilla, Microsoft and Adobe inked on the presence sheet (unfortunately Bruce Lawson from Opera was unable to make it), I was very much looking forward to this event. After all, the web community (especially the developers) had been waiting over two years for some clear stand on the subject of responsive images from the big players, while, in the mean time, and according to the latest stats, 72% of responsive websites were still serving the same amount of data to ANY device.

Use Cases

The day started off with a pre-recorded presentation of the problem at hand from RICG‘s front man Mat Marquis, and we quickly went to real case uses with an overview of the BBC and Akamai’s ways of handling the issue.

Very interesting to see what large scale companies had been implementing, especially since the BBC and its 83 millions monthly views (2.6 millions views per day), as Mark McDonnell explained, had been using none of the so-far-proposed solutions , but ‘a form’ of javascript-dependent responsive image system. Lightweight, fast working on all devices solution, and implemented since 2011.

I can only invite you to take a look at their project. The javascript is open-sourced and available on Github.

Next, Guy Podjarny took the stand to explain Akamai’s sophisticated content delivery acceleration techniques including smart delivery (with Edge Device Characterization) using patterns of characteristics drawn from a database of mobile devices, front-end optimization, the still-in-beta image converter allowing art direction, and adaptive image compression taking into account the network conditions to define the quality of the served content.

Quite a setup. Defo out of my league, and certainly destined to large scale sites. In a nutshell, not exactly what you would use to build the website of your local pub.

A look back at the Proposed solutions

DPR switching, Viewport switching and Art direction on our minds, and a few coffees down our throats, we went ahead and reviewed the proposed solutions.

  • Apple’s Ted O’Connor presented the `srcset` attribute, which defines the various image resources to be used, and the clues to help a user agent determine the most appropriate one to display, already implemented (at least a limited version of it) by webkit.
    <h1>
        <img alt="The Breakfast Combo"
             src="banner.jpeg"
             srcset="banner-HD.jpeg 2x, banner-phone.jpeg 100w, banner-phone-HD.jpeg 100w 2x">
    </h1>
    
  • The `picture` element presented by Mozilla’s Marcos Caceres, defining a declarative solution for grouping multiple versions of an image based on different criteria (format, resolution, orientation, and more), allowing the user agent to select the optimum image to be presented while providing the best solution (so far) for art direction.
    <picture width="500" height="500">
       <source media="(min-width: 45em)" src="large.jpg">
       <source media="(min-width: 18em)" src="med.jpg">
       <source src="small.jpg">
       <img src="small.jpg" alt="" lazyload>
       <p>Accessible text</p>
    </picture>
    
  • ‘HTTP Client Hints’ presented by Google’s Ilya Grigorik, which defines a set of HTTP headers allowing browsers to indicate a list of device and agent specific preferences, and drive servers to use these “client hints” to assist in content negotiation.

    Ideal solution as the content served would match the environmental conditions of the client, ideal in the minimal developer effort sense (I knew you would love that one!), and also ideal as far as semantic is concerned (ie. a simple image tag ).

    But… we would need to use a new header where we would define the devicePixelRatio (DPR) of the terminal (e.g. CH: dpr=2) to pass the relevant info to the server, the current UA header being unable to do that. More on client hints here.

  • The ‘SVG’s Switch element’ presented by W3C’s Robin Berjon, a solution already well supported today, already offering a built-in, working fallback. See his full presentation here.
    <switch alt="Accessible text">
         <img media="(min-width: 45em)" src="large.jpg">
         <img media="(min-width: 18em)" src="med.jpg">
         <img src="small.jpg">
    </switch>
    
  • ‘New Image Format’ presented by Yoav Weiss, a responsive image container containing internal layers which uses resizing and crop operations to deal with both resolution switching and art direction. In a nutshell, the encoder takes the original picture, the required output resolutions and if needed art direction pre-requisites, and outputs a layer per resolution.

    As a picture is worth a thousand words, there you go:

What now?

DPR switching definitely seems to have made the top of the vast responsive images todo list. I have to admit I freaking love the concept of client hints presented by Ilya, but Google will certainly need an ally if we are to go this way… and it doesn’t look like it could be Mozilla, David Baron having shown little enthusiasm (to say the least) to go ahead and add more (unremovable) HTTP headers.

The ‘srcset attribute’ and the ‘Picture element’ will make last call, and will definitely keep on getting tested. Both could emerge winners, srcset for its simplicity, and picture for its art direction friendliness, a popular aspect in the developers community.

Expect some simplification in the markup, and a likely removal of possibly w and more likely h from the spec.

Microsoft could have a card to play in this debate, with IE12 in the box, and a strong and obvious interest from Lead Principal Program Manager Israel Hilerio.

Final words

A huge bravo to Marcos and Yoav for getting a crowd of proactive folks and professionals going for eight hours straight, on the sole subject of responsive images. And a massive ‘thank you’ for opening the doors to smaller companies and freelancers.

Getting together is already a huge success, working together is the next step forward.

My name is Flo Preynat and I am the freelance webdesigner and developer behind shoogle designs. I live in France and specialize in responsive web design. Give me a shoogle or get in touch with me on twitter.

Most Recent Posts

Special Recent Posts

Make Google Charts responsive

Make Google Charts responsive

March 19th, 2014

A quick blog post on how to make Google Charts play nicely in responsive mode. Nothing close to rock[...]

Codekit 2 : even more steroids for us web developers

Codekit 2 : even more steroids for us web developers

March 17th, 2014

I was on holiday when Bryan released the new version of Codekit and never had the chance to to check[...]

Open terminal from folder in finder

Open terminal from folder in finder

January 27th, 2014

A quick one nudged my way by Adrien Joly this morning. You can now open a terminal window from a [...]

A look back at Wordcamp Paris 2014

A look back at Wordcamp Paris 2014

January 22nd, 2014

I went to Wordcamp Paris last week. The event was held On Friday 17th January at MAS Paris and Satur[...]

Gruntjs Boilerplate: my dummy-proof step-by-step guide

Gruntjs Boilerplate: my dummy-proof step-by-step guide

January 14th, 2014

Right so I've made the leap. After quite a ride, and some cool adventures with Codekit, I've deci[...]

Comments

  1. Caryophyllin says:

    Client-Hints is a maintenance nightmare, as you have to have width/height attributes on *every* image and you must have background-size on *every* background.

    Otherwise Client-Hints just makes images twice as large. It tells DPI to the server, but server cannot tell selected DPI to the client, so client always assumes low 1x DPI.

    Client-Hints is advertised as automatic, but it seems nobody really tried to use it on non-trivial website. I’ve had such custom system (based on UA sniffing and Cookies of course) and it was a disaster. There’s always some CMS-generated or odd template image that lacks width/height and ruins the layout.

  2. Flo, nice writeup! A couple of quick thoughts and comments on the Client-Hints stuff…

    With regards to David Baron’s comments, we didn’t get into the details at the event (perhaps we should have), but as I mentioned briefly during the presentation, I think his concerns can be mitigated by an opt-in mechanism. Specifically, the concern is that if CH hint were to fail (for whatever reason), it would be hard / near-impossible to remove it from the sent headers, which is the worst case scenario… However, if we assume that the server/site must first signal an opt-in (via an HTTP header, or a meta http-equiv), then this is no longer an issue — only sites that want it or need would trigger it.

    Ongoing discussion around this here: https://github.com/igrigorik/http-client-hints/issues/8

    In short, I think we can address David’s concerns – it’s not a blocking issue.