Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Picture Source src modification through CSS image-set and URI Templates
<style type="text/css">
picture source {
src: image-set(url({filename}@2x.{ext} 2x high-bandwidth));
@media screen and (min-width:321px){
picture source {
src: image-set(url({filename}-m.{ext}), url({filename}-m@2x.{ext} 2x high-bandwidth));
@media screen and (min-width:641px){
picture source {
src: image-set(url({filename}-l.{ext}), url({filename}-l@2x.{ext} 2x high-bandwidth));
@media screen and (min-width:1281px){
picture source {
src: image-set(url({filename}-x.{ext}), url({filename}-xl@2x.{ext} 2x high-bandwidth));
<picture alt="Alt tag describing the image represented">
<source src="photo.jpg"/><!-- This would be your smallest photo -->
<noscript><img src="photo.jpg" /></noscript>
This is my proposed solution to displaying images on multiple devices with multiple resolutions as an alternative to:
* Hat-tip to @adamdbradley who has lead the research on this and got me thinking in this direction.
* picture source selector used in CSS would only apply to source tags inside of the picture element.
* simplifies authoring picture elements and maintaining them.
* {filename} would use the file name of the src attribute of the selector, in this case it would be "photo"
* {ext} would use the file extension of the src attribute of the selector, in this case it would be "jpg"
* would require the browser to parse the CSS file before loading the src attribute of the source tag in the picture element to prevent duplicate downloads.
Copy link

adamdbradley commented May 2, 2012

I like it, but as you pointed out, an issue will be requiring CSS to be loaded before a picture source is requested. But what's great about using the 2x pixel ratio value in image-set is that it could tell the browser to half the natural width and height (so the image only takes the same physical display area as a 1x image).

One point to think about is that this is a blend of using image-set and media queries together, so should the solution use only image-set or only media queries? Since we're proposing new functionality anyways the questions will come up, "Why not just use another media query for bandwidth and pixel ratio, and not use image-set at all?" ...Or..."Why not modify image-set to also have break points, and not use media queries at all?"

Really both are valid questions, but I think it comes down to which of the three routes is easier to understand and maintain; mix of mq and image-set, mq only, or image-set only. What I don't like about the media query route is that all of a sudden our CSS becomes 50+ lines. However, if you cram all that info into the image-set format it may become hard to read. Maybe all three options should be made to work and let the best one float to the top?

No matter how you look at it, we're managing many different image variants and displaying them according to specific scenarios, its going to be difficult to organize. But overall I like this better than duplicating all of the same breakpoint and hi-res variants into the structure (but should still be an option).

Best part: if we put your CSS into an external stylesheet then we can call it a day; breakpoints in for responsiveness and image-set's in for hi-res, which would work site-wide. No duplication and centralized for maintenance.

Also, here's a link to URI Template (RFC 6570), which may help explain to others how URI templates would be useful (and how it can keep our code DRY).

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