Responsive Image Solutions: Picturefill and the <picture> element
Introduction
In the previous episode in this series, we looked at the simple responsive image solution called Fluid Images. In this episode, we are going to look at a solution that aims to address several of the issues we face with responsive images - using a solution called Picturefill. Picturefill is a popular solution to the responsive images problem within the web design community and has many influential supporters. In this article though, we will attempt to take a more level-headed and unbiased look at the merits and drawbacks of this solution.
A word of warning: I will be assuming a degree of technical knowledge in this article as I will cover specific details of this solution. Despite this, I will attempt to explain the gist of this solutions in a non-technical way, so even if you are not initiated into the dark arts of coding but are still curious - do dive in.
Picturefill
Picturefill aims to solve many of the key issues regarding responsive images. The solution has been developed by the Filament Group, who are in turn supported on this by the Responsive Images Community Group.
Picturefill is an attempt to bring two proposed solutions from the future into the present - namely: the proposed <picture> element and sizes & srcset attributes. These future solutions attempt to specify different images and the conditions under which each these should be downloaded to ensure the most appropriate image is used and downloaded by each particular browser/device.
The HTML markup for the <picture> element is only supported natively for the latest version of Chrome, Opera & Chrome for Android (currently in development for Firefox). Picturefill attempts to bridge the gap until there is wider support by allowing you to use a similar markup that is then transformed by the Picturefill JavaScript polyfill to enable support in other browsers. This of course all rests on the hope that these solutions will be widely adopted by most browsers natively in the future.
The latest version of Picturefill (2.0) uses the following markup for each of the options.
Picture element markup:
<picture>
<source srcset="examples/images/extralarge.jpg, examples/images/superlarge.jpg 2x"
media="(min-width: 1000px)">
<source srcset="examples/images/large.jpg" media="(min-width: 800px)">
<img srcset="examples/images/medium.jpg" alt="Tall Buliding New York">
</picture>
The <img> fallback is the only part of this that will not be in the final picture element specification.
This allows you to specify a picture using a similar syntax to HTML5’s video tag.
We can see here how different sizes of images are selectable based on media query-like device width conditions, with the first source element matching the device being used. The 2x syntax is an example of the shorthand that can be used for more complex resolution media queries i.e. to specify images for a retina device. We can also see that the srcset attribute is used here to enumerate the different images available per device width condition.
Picturefill also allows you to use a different option to use a combination of only the sizes & srcset attribute on the the img tag for example:
<img sizes="(min-width: 40em) 80vw, 100vw"
srcset="examples/images/medium.jpg 375w, examples/images/medium.jpg 480w,
examples/images/large.jpg 768w" alt="New York Stock Exchange">
Here the sizes attribute allows you to define a range of different breakpoints for deciding what image to use (an unspecified min-width is the default), and the srcset attribute enumerates a series of comma separated images with each images width specified. In this example we are using CSS3’s vw (viewport width - 1vw = 1% of the width). The combination of these two attributes then allows Picturefill to decide which is the most appropriate image to use for a given situation. An odd thing about this method is there has been no suggestion or effort (by those that created Picturefill) towards making this pure srcset option implemented natively by any future browsers (unlike the <picture> element & srcset combination). The reasoning behind why the pure srcset method should then be used appears strangely absent from most articles championing this.
Obviously there is the issue regarding how one creates the different images required for each of these methods. One solution is to pick a CMS that is able to generate these images for you automatically, such as the latest TYPO3. Another way to generate these images is to use a task runner like Grunt or Gulp. It should be noted though that using any automated method for generating images will negate the ability to address the art direction issue. For a website with even a moderate number of images – to use this method either one has to sacrifice the art direction or you have to take a double hit of increased work at production time and increased ongoing maintenance for the client every time even a single image needs to be changed, to ensure the alternate versions for that image are also selected and updated.
Another major disadvantage is that it ties the HTML to a particular design, as the breakpoints are hard-coded in the markup in the media queries (rather than only being in the CSS). This could make a simple re-design far more difficult. In addition, these multiple media queries are in every single picture tag, and need to be run for every single image/picture tag. This makes it an appallingly inefficient way to do things for a test that should only need to be done once.
In addition, one of the quirks of using this particular method means that browsers that have javascript disabled or encounter js errors will not receive a fallback image; they will only see the alt text instead.
Pros:
- Addresses the performance issue
- Addresses the screen resolution issue
- Addresses the art direction issue
- Uses similar syntax to related HTML5 tags like <video>
- A pure HTML solution to responsive images
Cons:
- More complex syntax to use
- Not ideal for legacy sites or sites with more than just a few images adding significant bloat, inefficiency and new markup
- Ties markup to a particular design, making re-design more difficult
- Makes website images more difficult to create and maintain especially if addressing art direction issue
- Poor fallback behaviour to simply alt text when js disabled or broken
- <picture> element currently only supported natively by the latest Chrome, Opera & Chrome for Android (with support in Firefox in development) with no guarantee that it will be widely adopted by other browsers in future
Conclusion
The Picturefill method and <picture> element are an ambitious attempt to address most of the main issues in responsive images – and indeed in theory it has the potential to do so. However despite being created and championed by some of the most respected voices in the industry - in practice, this method has so many drawbacks that could make it unsuitable for all but the simplest websites. The complexity and radical change in markup, and increased work both to create and then to maintain this method across all website images would make this a non-starter for many websites, let alone its poor fallback behaviour for non-supporting browsers and restriction to a particular design due to media queries in the markup.
To make it a little more viable by for example using an automated method of image generation would mean sacrificing one of its most lauded strengths (addressing the art direction issue). This is aside from the fact that this is a solution only adopted by 3 browsers natively at the time of writing this article – and rests merely on the hope that those who commit to this method will see it widely adopted amongst all future browsers – and is dependant on a javascript polyfill for use in other browsers.
Perhaps it’s greatest strength, attempting to solve all responsive image issues - has led it inevitably to its greatest weakness, being too complex and impractical to use for many websites.
In our next episode, we will examine a less well publicised and more modest solution to some of these issues – Adaptive Images.
Update 29th May 2015
The developers of Picturefill have recently discovered a bug in older versions (older than version 2.3.1) that may cause images to break under certain circumstances. They urge any users to update to the latest version of Picturefill to avoid any potential problems. To find out more about the nature of this check out their recent article.
Update 16th March 2016
Picturefill continues to be adopted very slowly. A recent survey in smashing magazine reported only 33% of people using the Picurefill solution in production for responsive images. Despite the best intentions of the responsive images group - this solution continues to struggle for widespread adoption - and perhaps with good reason!
Tweets by @respimgReferences & Further reading
Main website for the Picturefill method
Here you can find the details of how to use it fully explained, including downloads of required files.
Main Website for the Responsive Images Community Group
Main website for the group of developers that devised and proposed the <picture> element, and argue the merits of a pure front end solution for responsive image issues. Includes the full W3C specifications.
An article arguing in in favour of Picturefill by Filament Group
This article makes the case for why we should be using Picturefill - while acknowledging some of it’s weaknesses.
Another article making the case for why Picturefill should be used
A more biased article, highlighting only the merits of using Picturefill - without mentioning any of it’s weaknesses and drawbacks - pure Picturefill propaganda !
Article critical of the <picture> element approach
Highlights some of the main weaknesses of this approach in a non-nonsense straight talking article !
A more balanced article critical of the <picture> element
Highlights some of the main weaknesses of the current specification and why they won’t be using it yet - but also makes some constructive suggestions for improvement.
