Responsive Images

Are Coming!

Who????

Working on responsive images in my spare time for the last 2 years

A member of the RICG

A Blink & WebKit committer

Prototyped picture in WebKit. Implemented srcset in Blink. Implementing picture in Blink and WebKit.

I also been working on front end optimization server side solutions for the last 15 years, and am on a personal vendetta on image bloat on the Web

What is Responsive images?

Who knows what the responsive images problem is?

Efficiently load properly dimensioned images that fit the page's design

<history>

At the beginning

Mobile Web

And then

RWD

• Media Queries
• Fluid grids
• Flexible images

"Flexible images???"

"That's easy"

"Just send the largest possible image"

"And let the browser resize it"

EAZZZZZZY!!!

BLOAT!!!

Mobile experience became better, but slower

"a responsive site" became a synonym of "a slow site"

72% Serve same resources

guypo.com

Serving the same resources to mobile and desktop hurts performance

On mobile the images are much smaller and some of them are not even displayed

Which resources?

Images - over 63%

httparchive.org

How much can be saved?

Up to™ 72% image data savings

data plan abuse

large images mean long loading times

RWD sites got a reputation of being slow Web sites, mainly because of images.

People demanded a solution

Turned to the mailing lists

Proposals!

Moar proposals!

And MOAR!!!

And the RICG was born

<picture> proposal

The RICG discussed the issue for a few months and came up with the picture element proposal

srcset proposal

At the same time, Ted O'Connor from Apple proposed the srcset attribute for simple DPR selection

Hixie added it to the spec over the weekend without much public discussion, then tried to retrofit the other use cases into it

A lot of mailing list flame wars. Things got tense.

Picture vs. srcset!

Picture *and* srcset

Florian Rivoal (from Opera) proposed to join forces. the (original) srcset syntax was adopted into the picture syntax, since they covered different use cases

Browsers weren't convinced

9 months later

I prototyped picture in WebKit. Marcos and I Talked at TPAC. Marcos speced the proposal. Use cases doc. FPWD

But nothing substantial happened

Src-N

Then after a long while of little progress

SrcN was proposed by TabAtkins and John Mellor, after a couple of meetups we had with John.

It resolved all the use case, in a single element, but got resistence from some browser people.

Moar proposals???

There was a hecktic time at the end of last year, where proposals were coming in twice a day. But now this is all behind us.

Back to picture

The following an IRC chat I had with Simon Pieters, we figured out a way to gather up all the good pieces

from Src-N and wrap it inside something that looks really like the original picture syntax,

only significantly easier to spec, implement and maintain.

TabAtkins then revived the picture spec (basically rewrote most of it), and we've been working on it with Tab and

Simon ever since.

Mozilla were positive

Browsers liked it way better

Blink tho

Blink still resisted on implementation grounds, basically missing infrastructure.

So I got busy

Basically, I started tackling the infrastructure issues that were the cause for Blink's resistence, in order to defuse it

And realized that if I'd keep doing that in evenings, it's gonna take a looooong while

So, crowdfunding to the rescue

Patches got landing

~80 patches later

Blink work is done

WebKit is half way through

Shipped in Chrome 38

A group effort

XXXXXXX - Talk about Wilto and Geri and stuff regarding the IndieGoGo thing

The RICG & whatwg/blink folks are working together on the spec, to make it as awesome as possible. Mozilla is also heavily involved

The implementation in Blink and Gecko is almost done.

</history>

<syntax>

The srcset 'x' part

The oldest part of the spec, goes back to the WHAWG 2012 days

Use case

"Retina images"

Load hi-res images

on hi-res devices

Load fixed width high resolution images only on high resolution devices

<img src="1x.jpg" 
    srcset="2x.jpg 2x, 2.6x.jpg 2.6x" 
     alt="A giraffe.">

The <picture> part

Use case

Art direction

<picture>
     <source media="(min-width: 45em)" 
               srcset="large.jpg">
     <source media="(min-width: 18em)" 
               srcset="medium.jpg">
     <img src="small.jpg" alt="The president.">
</picture>

Here you can see the syntax parts that make up the "picture" part of the spec, namely the picture element and its source children.

Each one of the source children, as well as the img child define an image that fits into a certain responsive breakpoint.

Use case #2 - MIME type fallback

Today's Web have become fragmented when it comes to image formats.

We may not like it, but that's the truth :(

Picture will enable us to have client-side mime type fallback if we're using browser specific image formats, just like all other resources which they're type may or may not be supported (e.g. video, fonts).

Note that it doesn't mean that you can't do server-side content negotiation using the accept header, if that's your thing

But client-side may be more accessible to Web developers that can't mess around with their backend, and it has caching advantages.

Mime type fallback syntax

<picture>
     <source type="image/webp" 
               srcset="prez.webp">
     <source type="image/vnd.ms-photo" 
               srcset="prez.jpx">
     <img src="prez.jpg" alt="The president.">
</picture>

Here you can see the syntax parts that make up the "picture" part of the spec, namely the picture element and its source children.

Each one of the source children, as well as the img child define an image that fits into a certain responsive breakpoint.

The sizes + srcset 'w' descriptor part

The third part is IMO, the most exciting part.

This is the major innovation that the original src-N proposal brought

use case

variable width images

<img src="panda.jpg" 
     sizes="100vw"
     srcset="panda200.jpg 200w, 
             panda400.jpg 400w, panda800.jpg 800w,
             panda1200.jpg 1200w, panda2400.jpg 2400w"
     alt="A panda.">

<img src="panda.jpg" 
     srcset="panda200.jpg 200w, 
             panda400.jpg 400w, panda800.jpg 800w,
             panda1200.jpg 1200w, panda2400.jpg 2400w"
     alt="A panda.">

<img src="senator.jpg" 
     sizes="44vw"
     srcset="senator200.jpg 200w, 
             senator400.jpg 400w, senator800.jpg 800w,
             senator1200.jpg 1200w, senator2400.jpg 2400w"
     alt="A senator.">

Didn't add an example,so go over this example in length!

But wait, there's more

<img src="thumb.jpg" 
     sizes="(min-width: 1200px) 235px,
          (min-width: 641px) 24vw,
          (min-width: 470px) 235px,
          50vw"
     srcset="thumb100.jpg 100w, 
             thumb200.jpg 200w, thumb235.jpg 235w, 
             thumb470.jpg 470w"
     alt="Some animal.">

Didn't add an example,so go over this example in length!

Separation of concerns?

`sizes` is an optimization

All together now

<picture>
    <source media="(min-width: 641px)"
            sizes="(max-width: 1600px) 100vw,
                   1600px"
            srcset="sloth_bg_640.jpg 640w,
                    sloth_bg_960.jpg 960w, ...">
    <img src="sloth.jpg" 
         srcset="sloth_320.jpg 320w, 
                 sloth_480.jpg 480w, ..."
         alt="A rad sloth.">
</picture>

<img src="snowman.jpg" 
     sizes="(max-width: 580px) 100vw,
            500px"
     srcset="snowman_250.jpg 250w, 
             snowman_500.jpg 500w, ..."
     alt="A rad snowman.">

</syntax>

<support>

Implemented & shipped srcset's 'x' descriptor

sizes and srcset are fully implemented

Some infra is missing for picture, but I'll work on it soon

srcset 'w' usage

<picture> usage

srcset 'x' usage

</support>

<advice>

To picturefill or

OTOH, picture has a good fallback mechanism built in. Old browsers get the 1x src image

<picture> or srcset?

I get this question a lot. A simple rule of thumb: If you're doing art-direction, use picture.

Otherwise, you're probably better off with srcset and sizes

Source order matters

<picture>
     <source media="(min-width: 45em)" 
               srcset="large.jpg">
     <source media="(min-width: 18em)" 
               srcset="medium.jpg">
     <img src="small.jpg" alt="The president.">
</picture>

!=

<picture>
     <source media="(min-width: 18em)" 
               srcset="medium.jpg">
     <source media="(min-width: 45em)" 
               srcset="large.jpg">
     <img src="small.jpg" alt="The president.">
</picture>

Source-size order matters

sizes="(max-width: 30em) 100vw, 
     (max-width: 50em) 50vw, 
     calc(33vw - 100px)"

!=

sizes="(max-width: 50em) 50vw,
     (max-width: 30em) 100vw, 
     calc(33vw - 100px)"

'sizes' default value

<img src="otherpic.jpg"
     srcset="pic100.jpg 100w, pic200.jpg 200w">

<img src="otherpic.jpg" sizes="100vw"
     srcset="pic100.jpg 100w, pic200.jpg 200w">

Styling

"Picture is a magical span, nothing more"

- Tab Atkins

As far as styling goes, all the style that should impact the image itself, should still go on the img element.

Picture is simply a wrapper around that img, which as far as styling goes, behaves like a span.

Alternative text

Future compat

Feature detection FTW!

HTMLImageElement.sizes & HTMLPictureElement

The syntax may be extended in the future (e.g. with 'h' descriptors for height-constrained images).

Make sure your polyfill uses feature detection, and backs off when native support is detected.

Which resource was picked?

HTMLImageElement.currentSrc

</advice>

The path not (yet) taken

Client Hints

Content negotiation based

It's a complementary solution that allows for server side image adaptation, on top or instead of client side one

Future doesn't look bright, since some browser people are opposed to it

But, it may be a thing after all

To sum it up

Responsive images

are coming HERE!

Start with srcset

Build on top of that

The Web is ours!

Thanks!

@yoavweiss on Twitter & GitHub

responsiveimages.org

yoavweiss.github.io/smashingconf_whistler

Questions?