Common Questions and Concerns
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[1]: 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 [2]. 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 [3].
Previous attempts have included the use of cookies, dynamically-injected base tags, and clever hacks involving <noscript>. Then there are the experiments even less suitable for production implementation, including intentional misuse of the <video> tag and posters, and document.write. Through all of this, we have yet to find a solution that doesn’t rely on assumptions about browser behavior that may not always hold true—or solutions that fail completely in many browsers.
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.
Great write up 🙂
It may be worth pointing out that there is currently an advantage to using the server to do heavy lifting ( as noted in http://www.lukew.com/ff/entry.asp?1394 ) – however that is because of the current limitations of HTML to do this natively. Once there is a native way to do this on the client, there will be far less overhead slowing down small devices with low processing power.
As an aside; my argument for server-side adaption is about expanding possibilities rather than an OR solution. There are simply occasions where it is appropriate for the server to do work rather than the client – for example; generating the rescaled resources themselves, or adapting archived content where mark-up can not be changed and/or rescaled versions do not exist.
Oh, absolutely: that’s one of my favorite parts of this pattern. It would allow people to either hand-craft their image sources, or automatically crop/zoom on the server-side then output the alternate sources along with their markup. Viva flexibility, I say.
How about a reminder once again of why it is important to have images still within the markup when its appropriate? Just as MW had explained to me from my post.
I like the example of the picture element markup Scott put together in his picturefill example.
Though one thing I think that would be important is that, if a browser understands the picture element, to not download the src of the image tag inside of it, only the src of the of the active source tag.
Otherwise, the user will download two images, one from the active src of the source tag, and one from the src of the image tag inside the picture element.
Brett, that is surely the approach we’re trying to do. The whole responsive approach is to minimize the download-size. So it should be implemented in browser to not download this if already found a result before.
Agreed, if this issues has already been discussed, my apologies, just wanted to throw this idea out there. Looking forward to seeing the final solution this group comes up with!
One thing that just came to mind was how the picture element might handle images on hi-res devices.
A common approach for photos seems to be to create the photo at 2x the size and serve the hi-res image to capable devices and then serve the default resolution img to non hi-res devices. We already have phones and now tablets capable of hi-res displays and I’m sure laptops/desktops/ultrabooks/etc… will soon have hi-res displays. So if the current proposed solution to handling hi-res images is to just recreate the image at higher resolution, does that mean we would have something like the following to handle responsive/hi-res images: https://gist.github.com/2047740
If that is the case, browsers would have to make up their mind on device-pixel-ratio syntax. *Cough* Opera *Cough*. Preferably all would use min-device-pixel-ratio instead of using their vendor prefix in this purposed picture element.
Brett,
why are you defining all things twice? Why line 15-26? Makes no sense to me. There’s no difference between the images except pixel-size.
By the way: How do we handle attributes like width and height in picture element. They’re essential and should be required in picture-element, too, right?
I’m not sure where to put this: In picture-tag or in source-tag? Both has its own benefits.
Looking around, I have question that I haven’t seen addressed anywhere. Why
picture, rather thanimage? I appreciate that modifying the behaviour of the existingimgelement would be too tricky, but why not move to a non-abbreviated form?I agree that “picture” is not accurate as not all images are pictures.
Also, why not modify the image format itself? Something like the progressive format of JPEG, but have the browser stop downloading the rest of the file if it doesn’t need the progressive high-resolution data? I’m thinking of something along the lines of adaptive bit rates for streaming video.
This is what I always were voting for. I also pinged to WebP to do that. But no one heard this…
I don’t know the right people, if you do, spread the word.
Nevertheless it’s another approach. We need both, a responsive file-format (most likely WebP) and a HTML (markup-based) solution to serve diff. contents. Both have their own advantages.
@Mike, this was looked at, but
imageis used as an alias ofimgin some browsers.Everything seems to be focused on device width and serving up relevant images to those widths. I’m thinking the issue is more to do with not knowing how good a users connection is. Many users will be using the latest iPad with retina display on poor 3g connections yet with this solution will be getting served high res images because of their device width.
Am I missing something or is this not the best route to go down?
Nope you’re not missing something. This is what we have to solve also. But as a base we need our responsiveness first. Then we can talk about a media-query or similar to test against bandwidth. But we already have some proposals here…
I think that the idea of using a progressive jpeg or interlaced PNG sized to double the size required, and having the browser stop downloading once it has enough data for the resolution of the screen it has is a good one, except that the old-browser fallback is to download more data than they need.
Another thing to factor in is that most if not all desktop browsers have zoom functions, and it would be great if the high resolution version of the image could be filled in when the user zooms in. Some laptops have screens where the pixel size is very small, and users operate them in zoomed-in mode all the time, do different degrees, not just 2x
Couldn’t the browser request resolution-dependant ressources in the HTTP request header ?
Great article and response. Thank you for taking the time to write something concise, meaningful, and summarizing.