To Picturefill, or not to Picturefill
Posted by Scott on 09/26/2014
This week over at the always-bustling Responsive Images W3C mailing list, a thread discussing whether we should more commonly use the
sizes attributes instead of the
picture element (answer: yes, we more commonly should) eventually led to another discussion over whether to polyfill these features in unsupported browsers. Some commenters rightly pointed out that these new standard features are designed to fall back gracefully to a default image in browsers that don’t understand them (through the universally-supported
src attribute), and thus advised against polyfilling the behavior for existing browsers:
The fallback behavior is not something to be afraid of. It’s in fact just what we use on all the web today. Let fancy new technologies be just that, let browsers implement it when they want it, I advise agaist_(SIC)_ using picturefill on something as important as Drupal. source
…and frankly, I agree. Well, at least I want to agree. But in practice, I’ve found that right now the answer is not always so clear.
So take that disclosure as you will. In what follows, I’ll try to explain why I think it’s a good idea to polyfill responsive images today (either with Picturefill or another responsive images polyfill).
Why polyfill anything?
In essence, we use a polyfill when it brings an undeniable benefit to the user experience.
Why do we need responsive images?
The use cases for responsive image features are well-known: if you serve an image of the same size to all browsers, it can at best do one of two things:
- it can look big and sharp for everyone while being too heavy for many users to download, or
- it can be small and fast and look terrible on large and high-definition screens.
For many images, one source just isn’t enough to serve every user appropriately, and that’s why developers fought for a standardized approach.
Why polyfill responsive images?
Quite simply: it’s the responsible thing to do. Currently the
picture element is supported in zero stable browser versions. The
srcset attribute is now supported in a few browsers, but zero stable browser versions support
srcset paired with
sizes. Thankfully, users of “evergreen” browsers like the latest versions of Chrome, Firefox, Opera, Internet Explorer will gain support for these features very soon (and Safari too I’m sure!). But of course, users on browsers like IE 9 and older will never see native support for responsive images, and users on Samsung’s Chrome browser (the “Internet” app on any Samsung Android tablet) will have to wait for OS updates.
The problems that the RICG set out to address have existed for years, and developers have already been addressing them through whatever wacky means they could cook up. It’s fantastic that we are gaining native, standards-based features to address these problems, but it’s going to take a while for those standards to reach users that already need them. Using a standardized approach makes perfect sense, and yet the benefits that those features bring benefits all of our users, not just those in the latest browsers. A polyfill bridges that gap and makes sense for many of the sites we’re building today.
Yes, a couple. But I think they’re outweighed by the benefits.
Whoa… that second one! I know. I know.
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
src while using a polyfill, it will end up costing some of your users in double-downloads, and that’s not ideal.
The workaround recommended by Picturefill and the RICG is to omit specifying a
src. If you do that, the polyfill can still ensure that all JS-enabled users in existing browsers see an appropriate image, and native implementations will of course show an image now and forever (without needing the polyfill). I should note that
src is a required attribute per the specification; omitting
src means your markup will be invalid. It will still work in browsers that support the standard, but it’ll be invalid. As always, we have to weigh the costs and benefits and make decisions about these things. The more noticeable downside of this workaround is that if you omit
alt text instead. For many, this could be an unacceptable fallback. But
alt text is a standard fallback, and I think it’s often good enough for non-js use cases to consider the benefits this approach brings most users.
On balance, I think responsive images are often important enough to deliver to all users today, and polyfilling the standard is the best way to do that. I hope that in a year or more, we’ll see such broad support for these features that in many cases we’ll be able to start pulling this script out of our projects. I’m not sure many of us can afford to do that today.
Thankfully, with a well-built polyfill we can bring all users these benefits now without worrying that we’re placing a burden on users down the road.
At least for now, as both a developer and a user, I’m for it.