Picture/Picturefill Snippet

[adamjohnson]

From @adamjohnson on September 22, 2014 21:49

A snippet to add an image to the page using the <picture> syntax. Ideally CleanSlate would auto generate the image using the built-in tools and a user could choose their desired options based on the breakpoints in their site. The number of images generated could be added and subtracted dynamically or we could choose a fixed number (sm, md, lg, xl, 2x or whatever) of images to generate. Designers can optionally polyfill the <picture> element via Picturefill in their theme.

Copied from original issue: wvuweb/cleanslate#60

[adamjohnson]

This is a worthwhile read:

http://blog.cloudfour.com/dont-use-picture-most-of-the-time/

It basically says that about 75% of the time <picture> is not what we should use for responsive images. We should use srcset and sizes in an <img> tag instead. Picturefill can still be used as a polyfill for srcset and sizes.

I'm curious if

a) Browsers that support srcset and sizes in an image tag will download both the src and the srcset—causing duplicate downloads. This article seems like it's probable although that article is old-ish now. And... b) Browsers that don't support srcset and sizes in an image tag will fall back to the src (seems logical that they would).

Some testing would be required. If browser vendors have fixed the duplicate downloading issue in a), then we could potentially implement srcset and sizes by default in CleanSlate.

I can already hear people crying about "How do we know which sizes to use?" I'd argue this is a benign issue because the browser will choose the best available image via srcset and sizes. We could simply provide a wide range of image sizes and not worry about site-specific breakpoints.

If I (or interns) get time to test a) and b), I'll post back here with my findings. In the meantime, it might be more prudent to make an <img srset> snippet (naming suggestions encouraged).

[adamjohnson]

From @dmolsen on October 9, 2014 10:16

there is no duplicate download for a and they will fallback on b. creating a front-end for srcset sounds ugly.

an interesting first step might be just creating srcset listings based on the default resizing that clean slate does and stick those results in automagically. not perfect but closer to being the correct file sizes for the particular size of image.

[adamjohnson]

I think Dave is right for b based on this article from Scott Jehl:

Here’s the deal. If you specify a fallback image via a src attribute on your img (this is how you would normally specify a fallback image per the spec), any browser that does not yet support picture and friends will always request that fallback image over the network. This is true whether you use a polyfill or not, but if you do use a polyfill, that fallback image may not end up being the most appropriate image to display and another may be requested and shown instead. Regardless, the fallback image will be requested anyway and there's nothing the JavaScript can do to avoid that network overhead. So while you certainly can specify a fallback src while using a polyfill, it will end up costing some of your users in double-downloads, and that's not ideal.

I can't authoritatively confirm a yet. What's your source Dave?

Probably makes sense for someone to make an issue to talk about <img srset>. We have to decide if it's going to be a snippet or put in automagically as Dave suggests.

FYI here's the Can I Use browser support for srcset.

[adamjohnson]

From @dmolsen on October 9, 2014 14:47

You're overthinking it ;)

If a browser supports srcset and finds that attribute it knows to use that instead of src. On the other hand if a browser doesn't support srcset it'll ignore that attribute and only use src. Using a polyfill mucks with that because the browser does a pre-scan and fetch of resources before the JS has had time to run and "polyfill" in the srcset attributes. Hence the double download.

[adamjohnson]

From @zeroedin on October 9, 2014 14:50

:+1:

That is always going to be the issue with polyfills, they dont fully "replace" the standard browser action. Only overfill on top of them.

[adamjohnson]

Yes, that should be the behavior that happens, but it doesn't mean it happens that way right now. This stuff is still new.

[adamjohnson]

FYI srcset will be available in Firefox 38, due out in May. srcset compatibility at that time will be pretty damn good:

http://caniuse.com/#feat=srcset

That might be a good time to revisit thinking about responsive images.

[joshrcook]

There are so many variables here, it's hard to know where to start. Are you just talking about image replacement based on screen size, or are you also including pixel density and browser speed? There is a really good chapter in this book about some different techniques: Implementing Responsive Design

There are a lot of options already out there, from Adaptive Images (which I have used) to Foundation's Interchange (which I have not).

[dmolsen]

@joshrcook -

We're specifically focused on a mark-up focused solution using srcset and/or picture. There are back-end issues that have to be addressed too but the gist of this issue is thinking about what we can use on the front-end that will have broad support for responsive images and can be polyfilled.

[joshrcook]

@dmolsen -

Is there a reason you've chosen to use those those solutions over a javascript one? From what I can tell, both srcset and picture aren't very well supported especially on mobile browsers and IE, and I'm not seeing much community support in the way of a good polyfill.

[dmolsen]

@joshrcook -

Um, a polyfill would be a JavaScript solution. I'd call picturefill a pretty decent polyfill for both.

[joshrcook]

@dmolsen -

I guess I meant a purely Javascript solution, and I hadn't seen picturefill. That does seem to be a pretty well supported polyfill.