On Oct 11, 2012, at 12:36 PM, Ian Hickson <i...@hixie.ch> wrote: > On Thu, 11 Oct 2012, Markus Ernst wrote: >> >> IMHO as an author, the "bandwidth" use case is not solved in a future >> proof manner > > It's not solved at all. I didn't attempt to solve it. Before we can solve > it, we need to figure out how to do so, as discussed here (search for > "bandwidth one"): > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html
The RICG has proposed a solution to dealing with the overarching issue of bandwidth; it’s described in the following post: http://www.w3.org/community/respimg/2012/06/18/florians-compromise/ In the interest of keeping relevant information on the list, I’ll repost the relevant section here: It would assume a great deal if authors were to make this decision for the users. It would add a point of failure: we would be taking the bandwidth information afforded us by the browser, and selectively applying that information. Some of us may do it wrong; some of us may find ourselves forced to make a decision as to whether we account for users with limited bandwidth or not. To not account for it would be, in my opinion, untenable — I’ve expressed that elsewhere, in no uncertain terms. I feel that bandwidth decisions are best left to the browser. The decision to download high vs. standard resolution images should be made by user agents, depending on the bandwidth available — and further, I believe there should be a user settable preference for “always use standard resolution images,” “always use high resolution images,” ”download high resolution as bandwidth permits,” and so on. This is the responsibility of browser implementors, and they largely seem to be in agreement on this. In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion, rather than an imperative. srcset affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn’t want to introduce that sort of variance to the media query spec — a syntax long established as a set of absolutes.
