Big thanks to Adam Bradley for his feedback on this and helping me understand why this makes so much sense as an alternative way to author picture elements which makes them easier to maintain and keeps our markup DRY.

Also, Philip Ingrey reminded me that these can all be in one media query and that each vendor prefixed device pixel ratio doesn’t need to be in an individual media query. I must have had a mind blank when I originally wrote this. I’ve updated the markup to show his example which I think is a perfect solution to the “issue” I was describing. I’ve also moved some of the code examples to github.

I’m glad Philip reminded me of my mistake, because the markup I had imagined to handle all the vendor prefixes to do this was crazy.

On a side note, I’d love to see the user be able to choose if they want high-resolution graphics in their browser, just like they can choose their default font-size. Maybe an option where you can pick SD graphics and HD graphics. If they choose SD, it would say their device had a pixel ratio of 1 rather than 2 even if they were on a retina device.

Agreed, the picture element does start to get messy when you think about supporting multiple devices with multiple resolutions.

Matt Wilcox had some great ideas that I think would help alleviate some of that mess. One idea was to create a HTML element where media queries could be declared as variables and used in each picture element, keeping the markup DRY. I’ve put a gist together of my spin on this idea.https://gist.github.com/2509672

I think Christopher’s idea would work nicely with another idea Matt mentioned. Matt’s idea was having the picture element be able to support multiple image formats similar to how the video tag works. Here’s a gist of that my take on that markup.https://gist.github.com/2509735

Both solutions would be nice and are ideas I think should be considered before the picture element makes its way to a browser.

There’s a common theme in your code: the src attribute values have a filename, then the size of the photo, then the device pixel ratio (if its 2). This is for just one image, now imagine once its goes across your entire site. What about when you do a site redesign and instead of a breakpoint of 641px you change it to 721px? Or what about when you decide to also offer 1.5 or 2.5 pixel ratio versions, or remove 2 pixel ratios all together?

The source elements all have the same information, except a different filename. We’re repeating ourselves not only for every image variant, but also for every image on every page. When you look at just one example its fine, but what about when your blog has thousands? This format would help lazy authors create errors by forgetting to update parts of each source value after each copy/paste.

Matt Wilcox mqs head tag idea is great (https://gist.github.com/2509672), but this only alleviates duplicating the media queries within one webpage. But we’re still duplicating the filename pattern for each image, and media queries for each page.

Authoring the picture element with multiple child source elements and a media attribute should be an option. However, I believe the preferred method should be to control the image source with CSS: media queries that have different image-set()’s per breakpoint, and uri templates providing the request format (DRY).

Step 1 should be to get the picture element standardized which has already been largely discussed. But I believe that we’ll quickly see there needs to be a better way to maintain image variants and media queries on a large scale, and authoring presentational information into HTML is not it.

No matter how you look at it, it’s going to be complicated to manage numerous image variants and breakpoints. Our options are to either duplicate this complicated info for every image on every page, or centralize the craziness into one area.

Agreed! I see your point that a native HTML media query variable element would only work on one page. The only way to get it to work on other pages would be to add it to a PHP include. And if that’s the case, might as well just use PHP to create the media query variables. https://gist.github.com/1893129

I really like your idea of modifying the main image src via a URI template through image-set(). To me, the URI template is the missing piece of the image-set(). I didn’t see any information about it readying through the available documents on image-set() but I know you’ve implemented in foresight.js. Do you know if URI templates are part of webkit’s implementation of image-set()?

I’ve come to the same conclusion as you, “the preferred method should be to control the image source with CSS: media queries that have different image-set()’s per breakpoint, and uri templates providing the request format (DRY).” I think the issue will be making sure the browser only downloads the correct image from the image-set() in native solution for content images.

So far image-set() is a proposed solution when dealing with image variants for background images. But if this does become a standard then content images should follow the same format, rather than having one way to do background images and one way to do content images.

But no, image-set() does not use uri templates because it doesn’t need to for background images. However, I believe adding this feature into image-set() would make it much more flexible and powerful.

An entire website could format its hi-res and responsive images with one, or a small number of CSS classes all centralized in one location. But if authors choose to, they could still specifically code numerous source elements with repeated media attributes for every image variant on every page. I’d compare this to using inline styles instead of external css; sure there are times an inline style is all you need, however, an entire site should be designed with external css so you don’t repeat yourself and it’s easy maintain.

Adam, this sounds like the best solution to me. Being able to use image-set() CSS and URI templates natively on the picture element solves the issue of the mess the markup of the picture element can turn into when you start supporting multiple devices with various sizes/screen resolutions, as well as keep our code DRY.

I know you’ve seen my proposed markup for this on github Adam, but I wanted to bring the conversation back to the community. For those who havn’t seen it, I’ve put together a gist of how I see this idea could be implemented with the current picture element here: https://gist.github.com/2572749

This would be an alternative method to use the proposed picture element, as opposed to creating multiple source tags with various inline media queries.