This is silly and makes things way more complicated than they need to be.

We have HTML tags, to which we can apply attributes directly via blah=blah syntax

Or we can add attributes by making a style attribute, and using css syntax inside of it.

Or we can have a space separated list of class names, and have attributes applied to an element externally by a CSS stylesheet.

Or we can have an ID, and apply attributes using javascript.

We can apply attributes with http headers, and the browser can negotiate the resource with http accepts and quality parameters.

We have video, audio, and object tags that can all have child elements.

We have query parameters and fragment selectors, and path parameters, and post parameters and accept parameters for negotiating and selecting content from a server. (Designed to include ampersands which have to be entity encoded when used in HTML!)

We have all these sophisticated overlapping complicated mechanisms for attaching attributes to elements in a webpage. We have huge pieces of software for parsing through this poorly thought through mess.

But no, not a single one of these is good enough for this problem. LET'S INVENT A NEW SYNTAX AND ADD TO THE HEAP OF IDIOCY.

Previous discussion about this by developers (170+ comments) who have been discussing Responsive Images in a W3C Community Group - http://www.w3.org/community/respimg/2012/05/11/respimg-propo...

This really feels like the wrong approach to me - like this will lead to "best viewed with iPhone 5" pages.

Whilst there will be ways to automate the setting of such img srcset attributes based on the device (eg the PHP method mentioned that relies on a cookie) this sort of tailoring for specific device [characteristics] seems wrong somehow.

IMO this would be better handled by devices declaring their preferred viewport and/or pixel density just as they declare language preferences now, ie browser headers. Then the server can be set to send different images based on the header values and we don't have to worry about having a massive "srcset" attribute on each image tailoring to 500 different device variants. A server config would specify what viewport ranges to use and tell the server how to modify the images sent (or modify the path, or modify the location - eg switch an image with a folder called image.jpg and have filename tagged images for the different variants handled).

Perhaps this seems hacky too ...

In any case the SRCSET attribute proposal here looks short-sighted and hackish to me.

Or, here's just a crazy out there thought. What if we save our images in high res progressive format, and program the browsers to stop downloading the images as soon as they've acquired enough resolution? Caching can be done with http range requests. Older user agents just end up downloading larger images than they wanted. Javascript and server script can use the JPEGtran library to retrieve lossless low res versions of jpeg images. Similar things could be done with png. No modifications to any standards need to take place.

An alternative, completely server-side implementation: http://adaptive-images.com/

It takes the approach of setting a cookie when the page first loads with the viewport size, determined through media queries. Every request to the server then includes this cookie.

When an img is requested (as an <img> tag or through CSS background-image) the cookie is read to determine the viewport size of the client. The PHP script then serves up the most appropriate image size to the client.

The only thing you really need to do is add the .htaccess rule (to intercept image requests and route them through the PHP script), the php script itself and the highest resolution you need for each image. The script takes care of scaling down the image for smaller screens, caching them for later use.

I like the way this requires nothing on the client side, other than a cookie being set. All the heavy lifting is done on the server.

I like the concept, but the syntax feels awkward, clunky and very specific.

Why not repurpose the media attribute from style tags to all other tags?

Looks like a horrible solution which will add bloat and complexity to a webpage.

I would rather see a solution implemented with CSS or even a meta tag.

<meta name="srcset" content="2x=HD; 100w=phone; 100w 2x=phone-HD" />

The above example is exactly the same information as in this link. However it is expressed in one place and thus is far simpler. The only reason to do this per image would be if you different naming conventions for individual images.. which would just be silly.

You could then have a nosrcset attribute which you can add to images which do not have high-res versions. This would save an http request.

Better than this specification hassle is this solution:

The browser should send the density of the screen in ppi (calculated by the screen resolution and the screen information provided by the OS) together with all the other standard stuff like OS, screen resolution, etc.

With this information the server can decide which images to send.

> "2x" means "maximum pixel density of 2 device pixels per CSS pixel"

I don't understand why that's maximum pixel density and not minimum pixel density.

If I'm using a super-retina device with 4x pixel density, surely it's better for me to get the 2x image than the default (presumably 1x) image?

I agree that the syntax isn't great, and a corresponding set of CSS rules would be welcome, but this does solve a problem.

What I'd love to see is something similar for bandwidth sets, so lower bandwidth connections can be sent lower quality images. And then for both features to be made available for video tags.

I believe this should be moved to the stylesheet. We already have ways to determine media/viewport/device/orientation etc so adding different imgs would be a no brainer.

Bonus point, less cluttered HTML.

See also: https://etherpad.mozilla.org/responsive-assets for some other proposals.

I think lots of informal URLs consist U+002C COMMA character (,)

Why not <img srcset="url_1" srcset="url_2">? Is this against SGML syntax?

Here's an interesting example with <img srcset> http://junkyard.damowmow.com/507

When I saw the last line in the doc linked above, I realized that <img srcset=""> is probably optimized for adding one (1) "retina" image for iPhones and other high-DPI devices.

I don't care if the syntax is a bit unsightly. Let's just get this into shipping browsers as soon as possible. It's a major requirement for responsive design and this has good fallback behaviour. We can all just stick to 'mobile first' design and a .js polyfill shouldn't be hard.

Ian Hickson, the HTML specification editor, reasons in length about responsive images here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May...

They have started testing on different browsers.

http://testcases.glitchmr.pl/html/img-001.html

Responsive images are obviously needed but this syntax is noisy and confusing. Adding info after the file extension would make it too easy to overlook.