W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

Re: [whatwg] responsive images

From: Paul Court <paul@pmcnetworks.co.uk>
Date: Tue, 22 May 2012 11:53:27 +0100
Message-Id: <C518677F-5BE0-457C-83CF-3475EDFC4113@pmcnetworks.co.uk>
To: whatwg@lists.whatwg.org
I've been trying to follow this thread for a week now, but I'm a bit lost, so apologies if this is the wrong place.

As a HTML author and programmer, I just cannot see myself implementing the current srcset proposal on sites. As a programmer, it has very much got what we would call a "bad code smell".

<img src="face-600-200@1.jpeg" alt="" srcset="face-600-200@1.jpeg 600w 200h 1x, face-600-200@2.jpeg 600w 200h 2x, face-icon.png 200w 200h">

Not to mention, what happens when a 3x device is released?
Do I have to change all my code again?
I'm also confused about what exactly 1x and 2x are. Is it 2x 72 or 2x 96? 
and isn't 600-200@2 just the same as 1200-400@1?

Wouldn't it be more future proof, instead of making the author supply a never ending string of image names, implement variable logic (I think first suggested by Matthew Wilcox). However, instead of the suggestion of putting as a head <meta> tag, perhaps the logic could be confined to the <img> tag (or a <picture> tag to allow slightly smoother transition).

Perhaps something like this:-

	<img src="some-fallback.img">

You could then define a list of parameters that the browser supports as replacements. Eg. viewport-width/height, dpi, density. This could also be carried over to other tags.

It also allows the author to decide what to implement as a fallback / low bandwidth option. Personally, I could make: <img src="some_{width}-{height}@{dpi}.png"> return a perfectly valid image on my webserver if an older browser failed to substitute the params.

Like I said at the start, I'm a bit lost as a newcomer to the debate, but there seems to be suggestions floating around for better / more future proof / more elegant solutions than the srcset above, but they don't seem to be getting any traction.

Received on Tuesday, 22 May 2012 10:54:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:13 UTC