Responsive Images in Chrome and Firefox

Good News Everybody!

Professor Farsnworth says good news everyone — Professor Farnsworth has some good news, the picture element has arrived

If you’re viewing this in either Chrome* or Firefox** then the image above will be perfectly sized depending upon the viewport width. Not only is the image responsive within it’s container but thanks to the picture element it is serving up the best possible image size for your current viewport.

Amazing.

Responsive Images with a polyfill

A few months ago the picture element was ratified by the W3C and the browsers (Chrome, Safari, Firefox, Opera etc) began to make plans to develop the long awaited responsive images <picture> into the browsers.

We, as web developers, are not the most patient group of people and do not like to wait for something new — we want it NOW. In the cases of new features in HTML or CSS we want to start using the feature as soon as possible rather than wait for it to be developed and this is usually achieved when someone develops a polyfill — a pience of javascript that mimics the future behaviours of the browser — and that allows us to start working on including it within projects immediately (providing that your happy to include a js solution in a project).

Scott Jehl from Filament Group went about developing the Polyfill for the picture element so that allowed us developers to take advantage of the new approach and prepare our sites for when the browsers to add this to core.

If you want to get started with responsive images using the polyfill then head over to our resources page, download the javascript and check out the code pen to see how you can get started today.

Responsive Images without a polyfill

With our Polyfill in place we now sit patiently and wait for the browser vendors to get around to implementing the picture element into the browser. This involves waiting for browser developers to get through their existing work and move onto responsive images — and in this particuilar case it was not something the greater web development community was willing to do. We’ve been waiting for this moment and we want it NOW!

The community had an idea… the development time could be sped up if we fund the project as a community. And so the Indie GoGo page was created to raise enough money to sponsor Yoav Weiss to spend his time building the picture spec into Chrome and get it into production ASAP.

The work Yoav Weiss has done for the development for the Picture spec is now officially being shipped in the browser Chrome #38. That means that responsive images are going to be supported without requiring the Polyfill that Scott Jehl from Filament group put together.

Work has also been finished by Firefox and has begun with Safari (web-kit) and Microsoft are showing signs of developing this for Internet Explorer too.

For those of you that are running the polyfill you don’t have to do anything as the browsers begin to release the feature…. nothing will break if you use the polyfill and the browser supports the feature. You should keep an eye on Can I Use and make sure that once the browsers you support have a green tick next to the picture element you remove the polyfill so that there’s a little less JS on your site.

As a quick side note, the picture proposal syntax actually has a fallback built into it anyway. The polyfill is there to mimic the behaviour of the picture element and load the most appropriate image for the current viewport, however it will also fall back to <img src="images/professor-small.png" alt="Small version of the Professor" /> if you’re using the <picture> element for art direction, or fall back to the src if you’re just relying on srcset and sizes. If you want a full overview of the different implementations I recommend reading the RICG overview and Eric Portis review of srcset and sizes.

Okay then, lets get those browsers with support and start testing.

Picture fill in Chrome

*Okay, so when I said Chrome I really meant Chrome Canary with the a special flag turned on.

To get this up and running with Chrome and start testing you need to

Download Chrome Canary
Copy and paste the following into Canary’s address bar: chrome://flags/#enable-experimental-web-platform-features
Click “enable”
Test and file bug reports

Yoav tweeted that this will actually make it into Chrome 38 stable release.

Firefox

**Okay, so when I said Firefox I really meant Firefox Nightly.

To get Firefox Nightly up and running and start testing responsive image implementations you need to:

Download Firefox Nightly
Open the developer toolbar (shift + F2) or Tools > Web Developer > Developer Toolbar in your menu.
In the developer toolbar, enter pref set dom.image.srcset.enabled true
Test and file bug reports

Testing & Feedback

Every time I’ve built something there’s been a bug. It might not be critical, it might not be found before launch, but there’s always one or two of them tucked away.

This will be the same for the implementations of the picture proposal in browsers. I’ve already seen errors reported around animated gifs and .svg’s (see more about SVG’s below) so I urge you to test your own implementations and check to see

Is the correct image being served at the viewport?
Is only one image being served?
Is there any latency experienced in load times?

If you do find something wrong then file an issue on Yoav’s Blink GitHub along with an explanation use case and the browser/OS you’re testing.

Picture element structure

Update

Eric Portis was kind enough to comment and point out some errors with the original Professor Farnsworth image code I had posted.

The updated version looks like this…


<img 
  src="image/0017/4373/varieties/350-wide.jpg" 
  srcset="image/0017/4373/varieties/350-wide.jpg 350w,
  image/0017/4373/varieties/500-wide.jpg 500w,
  image/0017/4373/varieties/1024-wide.jpg 1024w,
  image/0017/4373/Professor-Farnsworth.jpg 2611w" 
  sizes="(min-width: calc(1140px * 0.7)) 1140px,
  (min-width: 64em) 70vw,
  (min-width: 37.5em) 95vw,
  100vw" 
  alt="Professor Farsnworth says good news everyone" />

Why does it look like this? Eric explains below

calc(1140px * 0.7)) 1140px is because the article has a width of 70% of the 100vw body, and a max-width of 1140px.

The rest (at breakpoints of 64em, 37.5em, catch-catch all at the end) mirror the breakpoints in your page and how the `article` responds to them.

To be even more accurate you could take the article’s padding into account; doing so would make the sizes more complex, though, and leaving it out is probably “good enough.”

Eric Portis with his recommendations on fixing our professor farnsworth image at the top of this article — Thanks Eric!

Eric also reminded me that the w declaration needs to be the same size as the pixel width of the image, i.e. 350px image = 350w, 500px image = 500, 1024px image = 1024w, and the original image was 2611px = 2611w.

Did you forget the SVG option?

Responsive images are great and coming up with a performant solution for raster images (raster = photos) has been quite difficult, although I think we’ve solved most of the problem with this new element.

If you are using vector based images then you already have a perfect multiple viewport solution — SVG (scalable vector graphic).

Professor Farnsworth above has been included using a raster image and I’ve chosen to include the following image sizes

300px (30kb)
500px (58kb)
800px (99kb)
1200px (155kb)

Professor.jpg is actually a perfect candidate for an SVG, however I couldn’t find a good SVG of him and this is perfect to illustrate the power of SVG.

The rest of the futurama crew below is an SVG image which means I don’t need any other versions than just this one. As it scales larger or smaller the vector points will redraw the image perfectly, regardless of how large or small the viewport, nor how many pixels you can squeeze into space.