First draft of HTML img srcset for responsive images
whatwg.org
whatwg.org
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.
Although in general things that make authoring easier are preferred, designs that are easy to implement in a bug-free way are generally preferred over designs that are complex and likely to lead to interoperability issues. After all, having to fight implementation differences is a rather common complaint about the web platform.
It also hasn't been clearly demonstrated that multiple elements are easier to work with. They are more familiar, but significantly more verbose. I don't know how that plays out in practice.
Using Javascript means you have to load scripts before the img tag, which can hurt performance.
Using http headers or a special URL format makes working with CDNs more difficult.
This is actually a tricky problem to solve and it looks like the authors have considered some of the above problems.
(I still hope they change it. Nested elements might be a way to go.)
Web Standards work requires you put up with a ton of really stupid things that people have been doing for a long time.
I think there are other good reasons to prefer the srcset approach, but not this one. The email here provides motivation: <http://lists.w3.org/Archives/Public/public-whatwg-archive/20...;
Now, he decides that actually this is the way to go. Frustrating.
For reference, in the email linked above, Ian Hickson said:
> So why not just give the UA the characteristics and a template to use to build the file names itself? That way we still give the UA all the same information, but it is much less verbose and still solves all the same use cases. Thus:
<img src="face-600-200@1.jpeg" alt=""
src-template="face-%w-%h@%r.jpeg"
src-versions="600x200x1 600x200x2 200x200x1"></code>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.
(yes, this is almost certainly a terrible way to implement it, but i was curious as to whether it could be shoehorned in.)
Additionally, trying to get browsers to consistently implement something of this level of complexity sounds dangerous.
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.
Why not repurpose the media attribute from style tags to all other tags?
http://www.libpng.org/pub/png/book/chapter11.html#png.ch11.d...
Yeah, stuff like "2x 100w" looks a bit like magic numbers[1]
Also there's potential for confusion in 'x' - does it mean X as in a co-ordinate i.e. width, or zoom? I'd rather see something more verbose like this:
<img src="foo.jpg">
<set src="foo1.jpg" width="100">
<set src="foo2.jpg" density="2">
</img>
<setsrc>
<img src="foo.jpg">
<set src="foo1.jpg" width="100">
<set src="foo2.jpg" density="2">
</setsrc>
<imgset>
<img src="foo.jpg">
<img src="foo1.jpg" width="100">
<img src="foo2.jpg" density="2">
</imgset> imgset img{display:none;}
imgset img:first-child{display:block;}
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.
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.
It breaks caching completely.
It requires scripting just to serve an image.
The same url can have different data - imagine if you resume downloading a file, only to suddenly have a different file.
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?
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.
Bonus point, less cluttered HTML.
Or, you use the newly minted 'defer' (I just came up with that) attribute to let the browser know not to download anything until the stylesheet is parsed.
<img src='myhugeretinapic.png' defer>Why not <img srcset="url_1" srcset="url_2">? Is this against SGML syntax?
There must be at least one height / width / pixel density descriptor for each url, so if you see a comma before the url ends, you know it must be part of the url.
<img>
<source src="house-hd.jpg" width="100px" height="200px" density="2x" />
...
</img>
Or something like that.
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.