Think I agree. I feel like we would expect to see a resolution is either normal or double in dimensions. But currently with media attributes we are able to set the image property in CSS by itself and it gives us much more control. Particularly useful in instances where our images aren't exactly normal or double in dimensions but are resized.
Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x?
The elephant in the room is, what "normal" and "double" even mean? It could be negotiating content based on something actually meaningful, like viewport size, DPI, even connection speed. This spec is broken as soon as we have to worry about something other than retina displays.
You can see they are basically getting this very vendor-specific hack they already had and calling it a standard. That's heresy.
Exactly. They should be reporting the resolution of each image in pixels, and leave the client to figure out what they want to download based on variables like connection speed, screen PPI, user settings etc. Trying to specify a scale just doesn't make sense, because the UA might be any resolution or multiple resolutions, might degrade for edge connections etc - the UA is best-placed to decide which images it wants, and that should be on the basis of source image resolution in pixels, not some arbitrary scale. Using 2x, 4x, 1280w is tied to the conventions of our current devices, which will change many times in the future, and doesn't provide useful information about the src image itself. Why do this?
They've done the same thing with resolution independence on iOS - instead of some sensible system of scaling and caching, we've ended up with a situation where images and icons are saved in several different versions by the developer just to cope with all the different possible resolutions/ratios using this sort of @2x naming scheme, and all based off arbitrary resolutions of screens which are going to change. It's a mess.
I think they'd be better with something like this:
<picture>
<source src="myjpg.jpg" width=100 height=100>
<source src="myjpglrg.jpg" width=1000 height=1000>
<img src="myjpg.jpg" alt="fallback img tag or text">
</picture>
We already have this scheme of source elements for audio and video, and this is the perfect moment to introduce something a bit more sane for images too. There's no need for the specification of arbitrary resolution intents if you give the src sizes. This would also let us transparently handle new file formats with fallback to older ones with type attributes, as with audio and video tags. For example you might start introducing SVG versions of many images, but leave a png source in there for older browsers.
The above proposal already displays perfectly fine in older browsers if you use an img tag within the <picture> tags for backwards compatibility, and could easily be dealt with in older IE with workarounds if necessary, though I think the img tag would display fine.
CSS can then be used to control the intended display size.
Not addressing anything else you raised but width and height are insufficient for making network performance and network budget decisions. Image size in pixels doesn't correlate that well with file size due to differences in color depth but mainly compression.
Image size in pixels doesn't correlate that well with file size due to differences in color depth but mainly compression.
Yes, that's true, though generally pixel size does relate quite well to file size for different versions of a given image on the web, and a picture element could just have sources in order of preference of use (regardless of size), so basically quality order - I think that's what the video element does (though for formats, not sizes)? The browser could choose different images depending on quality/bandwidth/resolution concerns, so it wouldn't always have to use the first. If not a quality attribute or something similar would be easy enough to add. I think the basic idea of the audio and video/source elements is fine, and should be extended to images as it could cover lots of use cases - don't really mind about the details as I'm sure they could be worked out.
The best way to get good retina images I've found so far is simply to oversize and compress heavily, which gives surprisingly good results and small files even for large images - I'd love to use something like the new picture element for multiple resolutions so that I could also provide a smaller version for lower bandwidth uses, but frustratingly webkit authors seem to see the picture element as somehow superseded by srcset, even though it doesn't do what a picture element would do, and introduces yet more headaches. I wouldn't consider using srcset for the reasons given above and because I've already experienced this solution in iOS dev, and it was equally broken there.
It's not providing the right information for a decision, it's trying to prejudge that decision based on one factor (screen resolution).
On top of that the syntax is awful and appears to have been chosen to make browser vendors' lives slightly easier - I went and had a look at the links you gave to hixie's reasoning, and it's all based on minor difficulties browsers had parsing audio/video, but they've already done that work, why introduce yet another sub format within an attribute?
The "2x" describes the image, not a property of the device that image is being viewed on.
If I have an image meant to be displayed in a 250x250 area of layout, a 500x500 "retina-ready" image will not fit. The browser must be told that the image is meant to be displayed "@2x" (as Apple puts it). This is what the "2x" is for. The browser is allowed to use any or none of that information in its decision making.
The syntax of srcset="" was chosen to match CSS's image-set syntax. The <audio>/<video> pattern wasn't great for anyone.
The multipliers refer to the ratio of device pixels to software pixels ("CSS pixels"). Content can be negotiated via viewport size, it's just that Webkit doesn't support that part yet. [0] The pixel ratio is better information than DPI, and connection speed is a difficult and unreliable metric.
It's also a total mischaracterisation of what happened here. This was not a case where someone implemented the feature and we were forced to go with they syntax for compatibility reasons. There was extensive discussion about the use cases, best approach, and so on. It turns out to be a much harder problem than you might have thought. For just one example of a subtlety, browser vendors find <picture><source> type syntaxes harder because they can't be processed atomically; for example:
<picture>
<source src="foo">
<script>document.getElementsByTagname("source")[0].src = "bar"</script>
[...]
is complexity that simply can't happen with srcset. Similarly one needs to consider the behaviour of preloaders in extant UAs; if existing browsers will start to download all the images that will create a much worse user experience in the short term.
I don't remember what all the considerations were here, but this is a much harder problem than many people give credit for, and certainly isn't a case where a single vendor controlled the whole process.
With respect, making life easier for browser makers is the worst possible reason to choose a feature which will be used by millions of documents (or not, in the case of srcset) over another with a better syntax. I'm not even clear why onload on an img tag would not also invalidate your img example above, but that doesn't even matter. Hacks for performance may be fine in browser or server code in some circumstances, but are absolutely not fine in a public document format like HTML.
Is the picture element containing source elements (like video and audio) still under consideration, or is srcset supposed to replace it somehow?
which is rather verbose and error-prone compared to srcset.
> Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x?
I don't think so (meaning of "1x" gradually changed from 72dpi to 100-130dpi, so I expect "2x" similarly gradually increase) and I proposed that new image embedding methods default to @2x, but that idea hasn't gained support from CSS/HTML WGs.
It could assume you are defining image dimensions in the stylesheet the way that normal image tags do. Or it can default to the image scaled down to 2ppx as defined in the media query. Your example looks similar to current audio tags.
<audio controls>
<source src="horse.ogg" type="audio/ogg">
<source src="horse.mp3" type="audio/mpeg">
Your browser does not support the audio element.
</audio>
I wish they had extended content negotiation to let the browser request an image near an ideal size in pixels using some kind of Accept header. Adding cruft like "med-hd" to the URL path is a design smell, and so is being able to suggest it from HTML but not HTTP.
That would be way saner, the problem is that it seems no one wants wants to touch HTTP. Browser vendors work under the assumption that whatever feature they implement, it only has a chance of being adopted if it can be hacked in other browsers with javascript shims.
It's not stupid. From an academic perspective, sure it works either way. From a business perspective, you have to support the full feature set on a given set of browsers, and you're not going to waste time on a solution that only covers 80% of your required browsers when you can write one codebase that covers all of your browsers.
Or have a progressive image format. Wherein the smallest/lowest quality image is at the front of the file and is enhanced by loading more data of the same file.
It should be up to the browser and the image file format to determine the best option.
JPEG2000 had awesome option of having progressive quality. During compression user could specify number of quality years, with each layer having specific compression ratios. Browser could download a chunk of JPEG2000 and render it, and depending on bandwidth available the browser would keep downloading and improving image quality.
Both Jasper support this (ilyrrates) and OpenJpeg (-r and -q) support this functionality.
I really wish the open-source JP2 situation was better. OpenJPEG is looking good but it's still in need of some performance work – which is a real shame since, as you pointed out, it'd be perfect for responsive imaging - just use HTTP byte ranges and it'd work with most proxies and caches, too.
That's not so great for high-latency networks (like most cellular networks). If you use range requests, you add round trips. If you cancel the load partway, you're too late because your pipe is already filled with bits you don't need.
That'd avoid the need to a round trip at all and it'd also be a huge improvement for caches which support HTTP range correctly since it'd be a single resource rather than multiple different URLs. It'd also allow browsers to start making decisions like selectively preloading more of an image which the user is likely to zoom, etc. although some of that would come simply from a good progressive JP2 implementation.
Manually specifying different HTTP ranges of the same resource is more verbose, more error-prone and more confusing than just specifying different resources. Other than that, I guess it would work.
> more verbose, more error-prone and more confusing than just specifying different resources
That's largely opinion: are byte ranges really better than having to maintain clusters of related images? Any serious site already has to deal with things like cache invalidation when a source file changes and by the scale of things which sites do for performance this is certainly no worse than, say, JavaScript/CSS minification or UA sniffing.
It would be less painful but still a problem: SPDY / HTTP/2.0 allows you to send more traffic over a connection but they can't do much for round-trip latency if you need to do something like ask what sizes of an image are available. That's particularly painful on cellular networks with a delay measured in hundreds of milliseconds – SPDY's ability to ship many things in parallel would only come into play after the browser knew which resources to request.
That would certainly be the cleanest solution, but I think we rely on so many old servers, CDNs, shared hosts etc that implementors (rightfully) worry that it would hurt uptake.
On the other hand, could that work without server-side code? If the logic is all done in the browser, you don't need support in your web server and you can still load pages straight from disk.
All it would take is some internal rewrite on the server, some directive to serve "lolcat_300dpi.jpg" when the client requests "/media/lolcat.jpg" with an accept header like "image/jpeg;dpi=300".
It would be way more flexible and even easier to implement, since you don't have to revisit all your markup.
If I may inject a shameless plug, this is exactly what http://www.pixtulate.com does to serve up responsive images and hi/low res images depending on screen resolution.
Yes, unfortunately we have to rely on a small client side javascript to detect your client's properties but the solution allows you to both upload and reference one and the same image and URL regardless of client and we'll scale, re-sample and even crop on the fly and cache the formatted image for future requests. We are trying to provide an experience as seamless as HTTP content negotiation.
> Theoretically, yes, but that means you need a pretty complicated setup to serve static assets.
Why? There's no difference on the server side, you would have multiple versions of the same file anyway. You're just exchanging the responsibility of getting the right file from the markup to responding with the right file on the server (which is way easier to keep consistent, IMO).
The way I see it, keeping it in the markup makes it more straightforward to debug. If it's server-side, all of our developers need direct access to the asset server as soon as there are content negotiation issues. If it's client-side, we can share a highly-available asset server and each developer has their code sandboxed.
In an ideal world, it would be server side. But it would easily mean twice as much work to get there.
> Using CSS to manage content images is broken by default, in terms of keeping our concerns separate.
I'm not sure I agree with this, in that I'm not sure there is such a thing as a "content image." Images on the web are presentational, full stop.
--well, okay, that's a bold statement. Let me put it another way: the "alt" attribute of the <img> tag is not only badly-named, it really shouldn't be an attribute at all. Ideally, this is what <img> tags should look like:
<img src="foo.jpg">bar</img>
with "bar" (previously the alt text) being the content, and foo.jpg being an alternate representation of the content, for supporting browsers.
Seen in that light, picking one visual representation out of several is exactly the job of CSS. (Though CSS is admittedly lousy for local rules right now. This would pretty much be the perfect use-case for scoped stylesheets!)
I agree, and there is already the less compatible <object> tag that works like that, at least in Firefox but Chrome fails to display the fallback when the image isn't available.
<img src="vacation.jpg">me standing in front of the Pisa Tower leaning towards one side with my hands like I'm keeping it from falling with a crowd of people around me doing the exact same thing</img>
I wouldn't, because he/she is blind. And I wouldn't describe him the flat picture I took, I would tell a story that includes observations from other senses that they can relate to.
Your case is a picture is not content. It's exactly what it is in many contexts (photography, illustration, charts). When a picture is only website decoration, then you're right.
To put it another way--web browsers and web spiders are (currently) blind, and they're the ones who define what "content" is, not users. Users only deal with the web through its presentation layer; it's machines who think on the semantic level, and so it's machines who get to say what is or is not semantically meaningful.
Illustrations and charts are frequently cases of "I just explained this in prose or as tabular data; now I'll give you an alternate visual representation of the same idea as well, to enhance your understanding". A chart would work perfectly well like this:
<img src="chart.png">
<table>
...
</table>
</img>
Likewise, a UML diagram for an algorithm might be represented thus:
<img src="sort_fn.png">
<code>
... pseudocode for sort ...
</code>
</img>
Photography is basically the one special case--where the medium (the shot composition, lighting, etc.) is a large part of the message. Still, unless the photograph was taken completely at random, there is usually a reason it is being included on the page. And that reason can be used as the non-visual text. (And note that, if the entire purpose of the page is to show you the image, then you're not really looking at a hypertext document. You're more looking at HTML+CSS being used as a layout format ala PDF. There is no semantic meaning to such a page, any more than there is to a PDF.)
Here's how I think of it--you should compose every page presuming the user is blind (and deaf, etc.) first--make your page work perfectly well standing alone like that--and then perform the same process of gradual enhancement that is recommended for javascript features, when you detect that the user can deal with image/audio/video/etc. content.
I think we need to ask ourselves whether providing the mechanism, markup or specification for which version of an image to load in order to maintain one and the same INTENT across clients should be the responsibility of front end developers/designers?
In my opinion, the only work the designer should have to do it to declare a particular image should be displayed. It should be the client<->server's responsibility to do its best in fulfilling that intent for each and every visitor.
To me, this is clearly a content negotiation issue and should not be solved in the form of verbose markup. Just because as designers we CAN always add markup, doesn't mean we should...not to mention the additional work of preparing multiple versions of the same image.
I've never commented on an author's English before, but why does this person write somewhat like Yoda?
> In our opinion not ideal, this markup pattern.
> Not too scary, this markup.
Is this an acceptable form of English grammar that I'm unfamiliar with? (I'm a native speaker, and this is an honest question.) Is he just trying to be playful with words?
It's called topicalization, and it's more common in some dialects of English than others. It's especially common in urban areas of the US Northeast. I'm from Long Island, and I didn't even notice he'd done it.
Interesting concept - I didn't know the word for this!
Though, the examples atop the Topicalization article still have all the words necessary for a more traditional grammar, just out of order. As highlighted in this article, the author has also dropped the implied "is".
I find this more common in spoken language, used by the speaker to inject a bit of variety and emphasis. I didn't realize it was a US-northeasternism, but I'm also not surprised to find in writing that's attempting an informal, spoken-word-like tone. It tends to set the observation off to the side, as if delivered in a different voice (stepping aside from the podium for a moment), or (as in some textbooks) like a comment printed in the side margin.
To answer the GP's question, it seems acceptable to me in an informal 'chatty' context, but you probably wouldn't find it in an academic/historical/neutral-journalistic composition. (I didn't read it as a specific attempt to invoke Yoda-style-speech.)
Yep I think he literally wrote those 2 sentences in a Yoda-style, intentionally, for playful effect. Rest of article is well written, with above average attention to sentence structure.
I'm from New Zealand, and I've lived in London for a while too - I've rarely heard anyone speak this way, and certainly it wouldn't be considered correct to write like that.
lowsrc was awesome. To conserve bandwidth I would often switch to lowsrc.
The new solution seem to be geared towards people running retina displays, without doing anything about progressive quality for people with low bandwidth.
Gross. Srcset is definitely not the solution here. Hacky, stupid, doesn't address the real problem. The real problem is that images only map to files in the most simple, rigid way.
The solution is to decouple images from URLs and to provide some client-side mechanism to resolve them based on an ID or name of sorts.
Instead of using static URIs, we should be providing resource names and allowing clients to resolve them based on their needs.
Instead of <img src="rock.png" />, we should be doing something more like <img name="rock" /> and allowing clients to decide how to resolve that. It may be a URI string, a data URI, a Blob, a canvas, etc.
The problem isn't low-res or hi-res. It's about how to serve particular images. There are a multitude of factors involved, and a multitude of ways to satisfy an image request.
It's not just about DPI, it's about bandwidth, request count, spritesheets, network conditions, and responsive HTML templates.
srcset is an ugly hack. A tiny DSL within an attribute value that only attempts to address DPI.
Everything else in HTML is more-or-less responsive - why aren't images?
Yup I'm not the only person to come-up with this. I think heuristically guessing how much to request from the content-length with two range requests would work just fine.
But it can keep the port open so a few round trips are saved, it might be fast enough to make the second request while the first was still coming in so effectively very little overhead, even on (especially on) high latency links where it matters most. It can start drawing even from the first range request, and the idea is to never pull down the entire file (for big files, the case you are optimizing anyway, small ones you don't really need to) and only maybe end-up pulling in the entire hires file with a third request if say the user zooms way in.
What bothers me isn't the name, but how the syntax looks like nothing else in HTML. At the time the idea was floated, there were a few alternatives talked about that mimicked the <video> and <audio> tags that made way more sense, and opened up for adding webp alternatives with png/jpeg fallbacks etc. It's a real shame they NIH'ed those.
That part in the article felt strained: Mat was clearly trying extremely hard not to be rude while showing how much cleaner <picture> is. Hopefully this is an opening salvo rather than the end of the discussion…
The problem with picture is that it doesn't poly fill nicely. You can add srcset attributes and it will still work on IE6. I have been using srcset for over a year, and there is is only a minor issue of retina MBPs double downloading. There is no problem with high res tablets.
I don't remember any issues polyfilling video, does anything make picture different? This is one of those things one person has to write once and then everyone can reuse it.
A polyfill of <picture> much more expensive. First you have to shiv IE to accept it as a DOM node. Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>. Polyfilling "srcset" is trivial as in:
if browser is modern and high-res,
replace the value of src.
else
pass
Doing a flash video polyfill of a video tag is okay because there is probably only one video on the page. Polyfilling <picture> would produce some seriously janky page rendering, and would be a pain in the ass to maintain.
In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning for anyone who isn't strict about pure semantic HTML, they could just stick an img in there for older browsers.
> First you have to shiv IE to accept it as a DOM node
I find this an increasingly weak argument as it's applying to <10% of the market and falling fairly rapidly ahead of the 2014 Windows XP end of life and is true of everything else in the HTML5 spec.
> Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>.
This is a reasonable complaint - I'm not sure I'd consider it a big deal since the work of manipulating the DOM is a lot faster than doing anything like downloading an image or rendering it but for anyone trying to do a wall of images it'd be worth benchmarking at the very least.
(<noscript> should keep browsers from loading the image tag, so you could do things like have JavaScript evaluate your image candidates and generate an img accordingly)
I'd prefer an extra tag during the migration stage to make the long-term goal more readable, particularly if we start wanting to extend it to do things like offer different image formats rather than just resolutions.
In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning you could use it as a fallback for legacy browsers.
I find this really disappointing, and it's another example of browser vendors and spec writers creating more problems than they solve. Even the best example here falls short:
and is fraught with problems. What does 1x and 2x mean in a world where devices range in ppi so dramatically, and single devices allow scaling from a rendered scale of 100ppi to 1000ppi (zooming on an ipad for example)? What actual resolution are these images (as opposed to display intent) and how do we find that out, by loading them all?
Including srcset in the picture element just makes things worse, not better, it's a confusion of a very good idea (allowing pictures to have multiple optional sources specified in the markup), and doesn't add any useful information, just gives hints as to rendering intent.
Here's how the concerns break down, from my point of view:
The HTML should provide a list of images to be displayed, in different formats and resolutions. It should not care about the device it is being rendered on, but it should provide as much info as possible on the source elements.
The CSS should specify the intent of the designer as to size and style (possibly suggesting different display sizes for different devices).
The User Agent (and thus the user) should be deciding which images to load and display based on the zoom level, the screen resolution, network, user preferences, and the image sizes available (as specified in html), designer intents, and future requirements we can't anticipate now. HTML works best when the markup doesn't try to second guess how it will be displayed and leaves that to UA.
srcset is a solution to a problem we didn't have, which will introduce all sorts of other problems in future (what is 2x resolution? how do we introduce new image formats?), and tries to stuff rendering intent into HTML where it doesn't belong. We'd be much better off looking at the picture element and improving it to include information on the actual image sizes (already possible), and letting the User Agent decide how to load and use those images.
Just as one example of unanticipated usage, a gallery plugin might read the source images available in some picture elements, and automatically construct a gallery from the thumbnails and hires images for each image. That's not possible with srcset and 1x 2x etc, but it is if picture elements have multiple sources at different specified sizes. e.g.:
<picture>
<source src="myjpg.jpg" width=100 height=100>
<source src="myjpglrg.jpg" width=1000 height=1000>
<img src="myjpg.jpg" alt="fallback img tag or text">
</picture>
Something is really broken with the webkit consultation process if changes like this can make it into the browser.
When the browser comes across this markup, it can request the correct image prior to finishing parsing the DOM or the CSSOM being ready.
I understand the appeal of <picture>, but the browser cannot choose the correct image until the DOM is parsed, the CSSOM is ready, and the page has been layed out. That all happens much later, which means the page will load slower.
I like the idea of <picture> but srcset is ideal if the only features you want are pre-loading and high-res support.
Do you have a mailing list discussion you can link to on this, that might be illuminating?
The reason webkit implemented srcset is because of the performance it allows.
I wonder what HTML would look like if browser performance was the primary concern? Is this truly the best argument for srcset, that browsers can parse the page quicker?
Probably the fastest HTML to render would be something like this:
There are good reasons we've moved away from that, even though it hits performance. It just seems wrong to be tying image resolutions to particular screen resolutions and trying to specify sources in a comma separated list with arbitrary resolution scales included, that's pretty nasty and not at all like other parts of HTML (which generally has been kept surprisingly clean if spartan in terms of features). I'd rather use js to load hires than use this or just serve everyone hires.
It reminds me of the horrible multiple resolution handling on iOS, which is probably what inspired it (@2x etc). I think there are now 15 different icon sizes for iOS [1] because of this insistence on tying resolutions to device specs. I can imagine issues with devices lying about resolution or ending up between x1 and x2 and not getting bigger images just because their resolution isn't quite x2 etc.
I see the concern on loading - if CSS determines the resolution of images, that would have to be parsed before deciding which image option to fetch, but that could be addressed by letting the browser decide which images are appropriate, and if necessary changing them if the CSS overrides that later. However I think the browser has far more pertinent info than the CSS writer (as long as it knows what size images actually are, not the intended device resolution in 2013!) about network, device, images, performance, user prefs etc. - the browser should decide what size of image is appropriate, and should be given the info to do that, and speed of loading should not be the primary concern in designing a document format - that should be a worry for browser makers, not for readers or writers of HTML.
The most convincing argument on the article page for me was a short comment pointing out the problem with srcset that it is tied to our expectations today of device specs:
If LG releases its Quad HD(?) smartphone screen it still means changing the html if you want to support it. - Niels Matthijs
Anyway, rant over, apologies for the long posts, I'll get back to work now, and thank you for taking the time to explain.
The example you gave confuses rendering performance with the ability to download assets in parallel / pre-load assets. Browsers can request images long before the CSS has even arrived. How does a browser know which image to preload when given multiple options?
Specifying multiple images in a way that in compatible with preloading, is more akin to concatenating javascript/css, putting css at the top, etc. It makes a big difference because it let's you cut the time-to-glass by an entire network round trip.
Sorry that example was too general, I was just trying to indicate that doc specs shouldn't be based on performance alone, as the most efficient format would be a memory dump like the old word formats or lots of inline style, clearly bad formats that we've moved away from. NB that concatting CSS does not change the doc spec at all, it's not the same kind of change either.
In the same way that the browser can choose to load higher res images based on resolution or breakpoint hints (srcset), it could choose to load higher res from a list of images without x2 etc but with image resolutions (picture with sizes). I would argue the browser choice should be based on far more than the HTML writer's ideas about device/display resolution at the time of creation.
To let the browser choose, the HTML could specify either original image sizes or some kind of desired resolution threshold for each image (srcset), but HTML should not know about the specific devices it is rendered on or include hints for rendering, I think that's an important distinction which is worth preserving. Not out of some desire for purity, but because separation of concerns stops bleed of concerns from one domain to the other and horrible messes later as the two domains become inextricably bound together.
I do think this is a terrible direction go in for that reason, it worries me that browser performance is used as the justification, and it would appear many agree with me, but we'll see by how much usage this gets I guess, I know I wouldn't use it because of the concerns above.
CSS px unit is not device pixel anymore. In this context 2x does not mean that the image is twice as big in px but that it should be used if the device pixel/px ratio is >=2
Concentrating on device resolution ignores many of the other bits of information a browser has when deciding which images to load. What happens when the device pixel ration is < 2, but the device is zoomed on the web page? What about slow connections on retina devices, or users who prefer to load things faster by getting lores images (something specifically called out in the spec)? Or some new browser which gets incredible first page render speeds by loading thumbnails of all images, and only loading hires images for those displayed? Or scripts which want to enumerate images and choose a certain resolution, independent of the intended display size?
This proposal is just making life easier for browser makers who want to cater for 2 resolutions in a hurry (ipad Retina, iPad), not for the people reading pages or creating them, and it puts the decision as to which image to render in the wrong place anyway IMHO. That should be a browser decision, based on data in the HTML.
After adding hidpi support to a small web app I am grateful that we are seeing progress in this area.
My solution was to use CSS media queries to selectively load different images. Using media queries this way felt like a kludge, and I knew there must be a better way. The new srcset attribute is definitely a step in the right direction.
Assuming Rails and other frameworks will add support for this I can see that at build time, or page generation time, our web frameworks will look for '@2x' version of images and automatically populate the srcset tag.
I had to do the same thing recently and ended up using "Interchange" from the foundation framework. I did have to hack away at the full background slider (supersized) to support this but it worked out nicely. The thing with media queries is that a browser window at 1400 doesn't fit the min-width:1400, in my case I had to use something like 1375 or some odd size. Maybe its some quirk with how matchMedia works ( what the interchange lib uses) who knows, I'll be glad when we don't have to go through these hoops.
Wait.. I thought it was some kind of set of sources of something (actual source code?). Granted, I'm not that versed in html/javascript, so I guess I'm missing the lingo.
The original attribute for a single image file is 'src'. srcset allows the browser to intelligently select an image (src) from a set of available images.
I can see from here the compatibility and complexity trainwreck we're going to have down the line.