Q: Wouldn’t a set of device-describing headers solve this?
A: Speaking just for myself: I’m all for a set of detailed gadget-describing headers, and would love to continue those discussions elsewhere. The more information about a user’s context we have at our disposal, the better.
I am, however, uneasy about the occasional “whatever, headers will solve this someday” sentiments dismissing the proposed markup pattern. There’s a big gap between having a screen size available on the server and a working implementation of the behavior we’re discussing—even assuming those headers are reliable it still puts the onus of a solid implementation on the developer, provides no benefit to the user, and only stands to introduce a point of failure.
We’ve seen standardized solutions that require a server-side component in the past with appcache, where setting MIME types was once required. This has since been removed from the spec due to overwhelming feedback from developers: the server-side requirement served as a major barrier to adoption for several reasons, including developers lacking direct access to servers, difficulty of implementation, and dependency on a server-side scripting language solely to take advantage of a feature inherent to HTML5.
Media queries exist to keep exactly this sort of logic on the front-end, and a markup-based approach follows the lead of other media elements that already solve their respective alternate-source delivery problems well: the <video> and <audio> tags.
Q: What about modifying the behavior of <img>?
A: We spent a great deal of time looking for ways to work with/around the img tag (and its alias in many browsers, “image”)—unfortunately, after speaking to several browser representatives, it was established early on that it was nigh impossible to modify the behavior of img to “look ahead” for multiple sources. Another major caveat is that any modification to the img tag stands to break things in terms of backwards-compatibility. Some of that discussion is documented in the conversation history on https://etherpad.mozilla.org/responsive-assets.
Q: Can’t we solve this with CSS?
A: It may one day be possible to use CSS to swap an image’s sources based on values set in data attributes, using existing proposals in draft specs . However, no proposed CSS-based solution accounts for one of the fundimental issues that we’re looking to avoid: downloading multiple assets at larger screen widths, as requests can be made before the swapping logic is applied. This leaves us waiting for implementation of a solution that will put us right back in the same place we stand with our current script-based solutions: attempting to work around a wasteful, redundant request.
Even if it does become technically feasible one day, it still leaves us in a position where our content itself is dictated by our CSS—it blurs the line between presentation and content.
Q: Aren’t there several script-based solutions to this problem already?
A: Such solutions have proven to be unreliable, and certainly not for lack of skilled developers or effort .
This is not to say it’s impossible. There’s no logical fallacy in this industry that bothers me more than “we can’t solve this, so it cannot be solved.” What this does speak to is the fact that we’re scraping the bottom of the barrel in search of a viable solution, and that search is causing us to creep further away from web standards. I’m certain I speak for everyone here when I say I’m uncomfortable with that.