CaraValence - Valence, May 2014
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
Efficiently load properly dimensioned images that fit the page's design
(fragments)Who knows what the responsive images problem is?
It started out (or at least got people's attention) as a quality issue.
The solution to that was simple - just send users the big images
Mobile experience became better, but slower
"a responsive site" became a synonym of "a slow site"
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
Images - over 61%
Up to™ 72% image data savings
tkadlec.com A small utility I cooked up and Tim Kadlec wrote about showed 72% data savingsdata plan abuse
This has turned out to be an abuse of our users data plans, which may be limited.Large images?
And abuse of our users' time. RWD sites got a reputation of being slow Web sites, mainly because of images.Turned into picture *with* srcset
The CG came up with the picture proposal, Hixie added srcset to the HTML spec.
A lot of mailing list flame wars. Things got tense.
Over time, the srcset syntax was adopted into the picture syntax, since they covered different use cases
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.
(John Mellor & Tab Atkins hashed it out over a bottle of wine, the legend says)It resolved all the use case, in a single element, but got resistence from some browser people.
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.
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.
Browsers liked it way better
Blink still resisted on implementation grounds, basically missing infrastructure.
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
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 is moving along nicely, and Gecko are happily implementing as well.
If all goes well, we may have the feature sihpping in a few months.
Let's take a closer look at each one of the parts combining the latest spec.
The oldest part of the spec, goes back to the WHAWG 2012 days
<img src="small-1x.jpg" srcset="small-2x.jpg 2x" alt="The president.">You can mix srcset's x descriptor with the overall picture syntax
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.
<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.
http://ericportis.com/posts/2014/srcset-sizes/
The third part is IMO, the most exciting part.
This is the major innovation that the original src-N proposal brought
It's the most exciting since it applies almost everywhere, once you look at it.
It can be used to save bandwidth in both responsive and adaptive designs and even if hi res displays are not involved.
<img src="otherpic.jpg" alt="The president giving an award." sizes="(max-width: 30em) 100vw, (max-width: 50em) 50vw, calc(33vw - 100px)" srcset="pic100.jpg 100w, pic200.jpg 200w, pic400.jpg 400w, pic800.jpg 800w, pic1600.jpg 1600w, pic3200.jpg 3200w">
I started out by implementing srcset's x descriptor. It shipped in Chrome/Opera stable a few weeks back.
sizes and the 'w' descriptor in srcset are done. I'll probably aim to ship it in M37
picture work has started and is moving along nicely - Christian is helping with stable state
xxxx Indiegogo campaignThey're showing up on IRC and mailing lists, asking good questions.
Implemented & shipped srcset's 'x' descriptor
Willing to accept patches behind a compile flag
I'm currently working on patches
(fragments)@yoavweiss on Twitter & GitHub