Skip to content

Instantly share code, notes, and snippets.

@aFarkas
Last active November 10, 2017 09:08
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save aFarkas/dcc87311232987591a16 to your computer and use it in GitHub Desktop.
Save aFarkas/dcc87311232987591a16 to your computer and use it in GitHub Desktop.
picturefill - gist

#Future of picture and srcset polyfilling

I believe that the best practices and most wanted default implementation of polyfilling/using responsive images will change in the near future.

While most people should omit the src attribute, if they use srcset in combination with pf. More and more people will want to simply use the default src as a fallback strategy.

Reason all major browsers now support srcset and sizes. And for all others the fallback src might be good enough.

At the same time, this progressive enhancement strategy doesn't work with art directed picture, because of two things:

a) picture isn't supported as widely as srcset b) and more important: art direction is a crucial part of the layout and not always open to a progressive enhancement strategy

This means people will want to include picturefill for polyfilling picture, but they don't want picturefill to interfere with thier fallback src strategy.

Another problem might be, that people might use different plugins with different strategies (polyfilling with no src attribute, polyfilling with low quality src or not polyfilling with medium sized src).

To serve these use cases, I would like to introduce a change in picturefill 3.1, which gives more respect to the initially set src by the developer.

The goal is to avoid double download, if the developer has set a initial src.

If the developer has set an initial src, picturefill does not run the normal source selection, it simply just checks, whether the current src is a) from the same set and b) is over 0.9x on 1x. devices or over 1.2x on 2x devices. If this is the case the current image candidate won't be changed.

Of course if the developer uses a) art direction or b) leaves out the src (as we currently recommend) or has choosen a dramatic low resolution image as src, picturefill works with the normal source selection algorithm.

So here are some code examples:

<!-- the following will be always polyfilled, although it has a src attribute (because art direction) -->
<picture>
  <source srcset="..." media="..." />
  <img src="..." />
</picture>

<!-- the following will be always polyfilled, although it has a src attribute (because image is not in set) -->
<img src="fallback.jpg" srcset="a.jpg 300w, b.jpg 600w" sizes="280px" />

<!-- the following will be always polyfilled, although it has a src attribute (because image is too small) -->
<img src="a.jpg" srcset="a.jpg 300w, b.jpg 600w" sizes="350px" />

<!-- BUT -->
<!-- the following will **not** always polyfilled, because a.jpg is often good enough fallback -->
<img src="a.jpg" srcset="a.jpg 300w, b.jpg 600w" sizes="280px" />

With this mechanism. Different image embed techniques (use img with fallback src) as also use picture or srcset only with polyfill can coexist friendly on the same side and picturefill adapts automatically to those different patterns.

@aFarkas
Copy link
Author

aFarkas commented Sep 30, 2015

What do you think guys?

@quoo, @Wilto, @scottjehl, @albell, @mike-engel, @jegtnes, @joemcgill

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment