I\u2019ve 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 \u201cresponsive images\u201d noise.<\/p>\n
More and more it seems that it\u2019s a waste of effort trying to retrofit the original Florian joined the list by posting a brilliantly thought-out compromise between the two syntax patterns<\/a>. I\u2019d like to share my thoughts on this proposal here, as I feel it combines the strengths of Let\u2019s begin by taking a look at the proposed syntax.<\/p>\n The chain of events followed by the above markup pattern are:<\/p>\n In terms of selecting a source element, this markup leverages all the strengths of media queries \u2014 the syntax created for this very purpose \u2014 to handle the \u201cart direction\u201d use case that Jason Grigsby has illustrated so eloquently<\/a>.<\/p>\n However, as has been detailed at length on the WHATWG mailing list and elsewhere, Once we\u2019ve used media queries to determine the most appropriate It\u2019s 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 The dark cloud hanging over all these discussions is the concept of \u201cbandwidth detection.\u201d We cannot reliably make assumptions about bandwidth based on client capabilities \u2014 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.<\/p>\n 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 \u2014 I\u2019ve expressed that elsewhere, in no uncertain terms<\/a>.<\/p>\n 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 \u2014 and further, I believe there should be a user settable preference for \u201calways use standard resolution images,\u201d \u201calways use high resolution images,\u201d \u201ddownload high resolution as bandwidth permits,\u201d and so on. This is the responsibility of browser implementors, and they largely seem to be in agreement on this.<\/p>\n In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion<\/em>, rather than an imperative. It seems In order to better wrap my head around this pattern, I\u2019ve updated Scott Jehl\u2019s Picturefill<\/a> to make use of the proposed syntax. The source code is available on GitHub<\/a>, and I\u2019ve posted a demo<\/a> as well.<\/p>\n I\u2019ve been discussing the implementation details of this pattern with several vendors recently, and the feedback has been extremely promising.<\/p>\n I\u2019d love to hear everyone\u2019s thoughts on this compromise, and through your feedback put together a set of formal proposals: a change proposal returning 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 \u201cselectively loading assets\u201d arena \u2014 nor does it have to be, right now.<\/p>\n There will always be limitless room for improvement when it comes to markup \u2014 a better way to handle source management for rich media<\/a>, for example. But we can\u2019t solve everything now \u2014 we can\u2019t fall into the trap of seeking the perfect solution<\/a> all at once.<\/p>\n 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 \u2014 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\u2019m confident that this syntax affords us that opportunity.<\/p>\n We can\u2019t predict the future. We can only strive to be future friendly<\/em>, while solving the problems of today. I\u2019m confident this proposal does so.<\/p>\n","protected":false},"excerpt":{"rendered":" I\u2019ve 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 … Continue reading srcset<\/code> proposal to cover all the use cases of the original picture<\/code> proposal. As we attempt to do so, the srcset<\/code> microsyntax grows and more and more confusing, and shares an increasing amount of overlap with media queries. To those ends, I asked Florian Rivoal \u2014 editor of the media query spec \u2014 to join the discussion on the WHATWG mailing list and offer his perspective.<\/p>\nsrcset<\/code> and picture<\/code> in a practical and logical way.<\/p>\nSample Markup Pattern<\/h3>\n
\r\n
\r\n<picture alt=\"Description of image subject.\">\r\n <source srcset=\"small.jpg 1x, small-highres.jpg 2x\">\r\n <source media=\"(min-width: 18em)\" srcset=\"med.jpg 1x, med-highres.jpg 2x\">\r\n <source media=\"(min-width: 45em)\" srcset=\"large.jpg 1x, large-highres.jpg 2x\">\r\n <img src=\"small.jpg\" alt=\"Description of image subject.\">\r\n<\/picture>\r\n<\/code>\r\n<\/pre>\n\n
picture<\/code> element is unsupported, the img<\/code> contained therein is shown as fallback markup.<\/li>\npicture<\/code> is supported, use media<\/code> attributes to determine which source<\/code> element best suits the user\u2019s viewport.<\/li>\nsource<\/code> element has been selected, the srcset<\/code> attribute determines which image source is best suited to the user\u2019s screen resolution. If only a single resolution is necessary, the src<\/code> attribute will function as expected.<\/li>\n<\/ol>\ndevice-pixel-ratio<\/code> media queries are poorly suited towards these decisions. As an author, using vendor-prefixed min-device-pixel-ratio<\/code> media queries in the example above would involve a massive amount of text and twice as many source<\/code> 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.<\/p>\nsource<\/code> element, srcset<\/code>\u2019s originally intended usage becomes absolutely ideal for our purposes: simply determining the appropriate image source for a user\u2019s resolution.<\/p>\nsrcset<\/code> on an img<\/code> tag for simply preforming resolution switching, nor does it preclude the use of picture<\/code> as originally proposed, with src<\/code> in source<\/code> elements rather than srcset<\/code>.<\/p>\nBandwidth<\/h3>\n
srcset<\/code> affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn\u2019t want to introduce that sort of variance to the media query spec \u2014 a syntax long established as a set of absolutes.<\/p>\nsrcset<\/code> won\u2019t be going anywhere, and that\u2019s not an indictment. There is a time and a place for srcset<\/code>. I feel that place is resolution switching, as it was originally intended. Our best efforts to bring srcset<\/code> closer in-line with the originally proposed picture<\/code> 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 \u2014 countless new potential points of failure.<\/p>\nAn Updated Polyfill<\/h3>\n
Next Steps<\/h3>\n
srcset<\/code> to its original resolution-only syntax, and a proposal for picture<\/code> that focuses on the \u201cart direction\u201d use case and optimization for client displays through media queries, excluding resolution.<\/p>\nThe Constant Caveat<\/h3>\n