I’ve been fairly quiet in this group for a while now. Part of that was wanting to let the dust settle on all the chaos that was surrounding this topic a few short weeks ago, and part of that was giving myself some time to digest the bits of signal that came through amidst all the “responsive images” noise.
More and more it seems that it’s a waste of effort trying to retrofit the original srcset proposal to cover all the use cases of the original picture proposal. As we attempt to do so, the srcset microsyntax grows and more and more confusing, and shares an increasing amount of overlap with media queries. To those ends, I asked Florian Rivoal — editor of the media query spec — to join the discussion on the WHATWG mailing list and offer his perspective.
Florian joined the list by posting a brilliantly thought-out compromise between the two syntax patterns. I’d like to share my thoughts on this proposal here, as I feel it combines the strengths of srcset and picture in a practical and logical way.
Let’s begin by taking a look at the proposed syntax.
Sample Markup Pattern
<picture alt="Description of image subject.">
<source srcset="small.jpg 1x, small-highres.jpg 2x">
<source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
<source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg 2x">
<img src="small.jpg" alt="Description of image subject.">
</picture>
The chain of events followed by the above markup pattern are:
- If the
pictureelement is unsupported, theimgcontained therein is shown as fallback markup. - If
pictureis supported, usemediaattributes to determine whichsourceelement best suits the user’s viewport. - Once an appropriate
sourceelement has been selected, thesrcsetattribute determines which image source is best suited to the user’s screen resolution. If only a single resolution is necessary, thesrcattribute will function as expected.
In terms of selecting a source element, this markup leverages all the strengths of media queries — the syntax created for this very purpose — to handle the “art direction” use case that Jason Grigsby has illustrated so eloquently.
However, as has been detailed at length on the WHATWG mailing list and elsewhere, device-pixel-ratio media queries are poorly suited towards these decisions. As an author, using vendor-prefixed min-device-pixel-ratio media queries in the example above would involve a massive amount of text and twice as many source elements. This could get unwieldy for authors very quickly, a concern voiced numerous times in these ongoing discussions. Further, implementation of MQ-based resolution switching is far more difficult on the UA side: a very real concern.
Once we’ve used media queries to determine the most appropriate source element, srcset’s originally intended usage becomes absolutely ideal for our purposes: simply determining the appropriate image source for a user’s resolution.
It’s worth noting that this example is, in fact, the most convoluted this element can ever be. This pattern in no way precludes the use of srcset on an img tag for simply preforming resolution switching, nor does it preclude the use of picture as originally proposed, with src in source elements rather than srcset.
Bandwidth
The dark cloud hanging over all these discussions is the concept of “bandwidth detection.” We cannot reliably make assumptions about bandwidth based on client capabilities — a MacBook Pro with a Retina display may be tethered to a 3G phone; a high-resolution mobile device is as likely to be connected to WiFi as it is an EDGE connection.
It would assume a great deal if authors were to make this decision for the users. It would add a point of failure: we would be taking the bandwidth information afforded us by the browser, and selectively applying that information. Some of us may do it wrong; some of us may find ourselves forced to make a decision as to whether we account for users with limited bandwidth or not. To not account for it would be, in my opinion, untenable — I’ve expressed that elsewhere, in no uncertain terms.
I feel that bandwidth decisions are best left to the browser. The decision to download high vs. standard resolution images should be made by user agents, depending on the bandwidth available — and further, I believe there should be a user settable preference for “always use standard resolution images,” “always use high resolution images,” ”download high resolution as bandwidth permits,” and so on. This is the responsibility of browser implementors, and they largely seem to be in agreement on this.
In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion, rather than an imperative. srcset affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn’t want to introduce that sort of variance to the media query spec — a syntax long established as a set of absolutes.
It seems srcset won’t be going anywhere, and that’s not an indictment. There is a time and a place for srcset. I feel that place is resolution switching, as it was originally intended. Our best efforts to bring srcset closer in-line with the originally proposed picture element only stand to leave us with a siloed microsyntax that inconsistently serves the purpose of media queries. With that comes further opportunity for errors by implementors and authors alike — countless new potential points of failure.
An Updated Polyfill
In order to better wrap my head around this pattern, I’ve updated Scott Jehl’s Picturefill to make use of the proposed syntax. The source code is available on GitHub, and I’ve posted a demo as well.
Next Steps
I’ve been discussing the implementation details of this pattern with several vendors recently, and the feedback has been extremely promising.
I’d love to hear everyone’s thoughts on this compromise, and through your feedback put together a set of formal proposals: a change proposal returning srcset to its original resolution-only syntax, and a proposal for picture that focuses on the “art direction” use case and optimization for client displays through media queries, excluding resolution.
The Constant Caveat
It seems I always end my posts in much the same way, but it always seems to ring true: this solution is not the ultimate solution to every problem in the “selectively loading assets” arena — nor does it have to be, right now.
There will always be limitless room for improvement when it comes to markup — a better way to handle source management for rich media, for example. But we can’t solve everything now — we can’t fall into the trap of seeking the perfect solution all at once.
Our goal is a laser-focused solution with the potential to fall in-line with other rich media elements, as we solve the greater issues one by one — issues of bandwidth detection; issues of organization. Our goal is to solve a very real and increasingly urgent problem, in a way that serves as a canvas for future enhancements. I’m confident that this syntax affords us that opportunity.
We can’t predict the future. We can only strive to be future friendly, while solving the problems of today. I’m confident this proposal does so.
