I don’t want to be that guy that swoops in and corrects things in blog posts—I really don’t—but there are a couple of shaky premises in here and I don’t want people left thinking this is a solved problem.
First, the two proposals aren’t competing. I want to put that out there right away—the two solutions, in combination, serve to address the list of use cases we’ve outlined at http://usecases.responsiveimages.org
In terms of a “responsive image format,” a great deal of discussion around this has already taken place in the RICG. The issue is that this—like image negotiation based on bandwidth, as you mention—is also 100% in the hands of the browsers. However, there are a couple of additional catches: first, the development of this alternate format has to be funded by the vendor(s) and they have to do so while 100% willing to share this format with all other vendors, even if they’ve chosen not to pitch in. The developing vendor(s) would be left footing the bill. As you can guess, the browser reps we’ve spoken with don’t really consider this to be an option.
The other issue is that there wouldn’t be any predictable fallback. JPEG2000 has still seen little-to-no adoption and can’t reliably be used today, but when chucked into an `img` tag it will still be requested by the browser. Then we’re left with the issue of providing a fallback, after that wasted initial request—we can’t exactly feature-detect for an image format. We’d have the option of doing content negotiation on the server-side, based on UA detection, but that’s about all. It should be noted that a part of the `picture` proposal is that each `source` would accept a `type` attribute, allowing UAs to skip over sources of unrecognized types, for this exact reason.
We regards to art direction not belonging in markup: it’s a markup issue as much as the size and cropping of any content images are—otherwise we’d be using the same size images for everything and managing it with CSS. Don’t get hung up on the “art direction” name; this isn’t stylistic so much as a matter of ensuring that the content being delivered is appropriate to the user’s context.
Implementation-wise, too, it wouldn’t be a matter of adding a quick cropping feature in CSS—not on a production-scale site, unless you knew the primary subject matter would always be in a certain part of the image. At best, you could hope to create a custom CSS framework where you’re relying on scaling and `overflow: hidden` to focus on (still pre-determined) parts of the image. You’d end up with an inflexible art direction system that still forces users to download a larger image than they’ll potentially need.
I agree that responsive images aren’t much of an issue in the multi-column wireframes you’ve posted, but those designs may not be a good fit for what’s being proposed—the idea is not that you’d be required to use this in every case where images are being resized, but rather in the case of large “hero” images—the Boston Globe’s Magazine page was what started us down this path, and still serves as a great example. Further, the size of the containing element isn’t an unknown, and we don’t need the image to be aware of it any more that other parts of our layout have to be inherently aware of their containing element’s size. It’s up to the designer/developer to choose image sources that are appropriate to that part of the layout.
Re: not living with the problem long enough—I assure you, many of us have. This has, with no exaggeration, been my unpaid part-time job for the better part of a year now. Of course there are flaws with the proposed standardize solutions to this issue, but many much, much smarter people than I have been working on solving this for a very long time now. If it were a matter of just having a “eureka” moment, I doubt we’d be where we are now. In the meantime—my full-time job—I’ve been using Picturefill (which mimics the proposed markup pattern) on day-to-day client work. I’ve had great luck with it so far.
I want this to be done and solved more than anyone; I do. I’m doing the best I can, and the other members of the RICG are working just as hard on this—and harder, in many cases. But this isn’t solved, and nebulous statements like “we just need a new image format” or “let’s just come up with something better” don’t get us any closer to a solution. If a better solution were to come along, that would be the end of it. If anyone reading this should have one, I welcome it like you would not believe.
Not doing anything about this problem, however, is not something I consider an option. It smacks of perfect solution fallacy, and passing on an option because it isn’t perfect means failing our users for the sake of theoretical purity. I’m not willing to do that; nobody should be.
I urge anyone who finds themselves interested in this subject take the time to familiarize themselves with the work being done by the Responsive Images Community Group, and read through the prior discussion at http://lists.w3.org/Archives/Public/public-respimg/, http://www.w3.org/community/respimg/, and http://lists.w3.org/Archives/Public/public-html/
Mat Marquis
I don’t want to be that guy that swoops in and corrects things in blog posts—I really don’t—but there are a couple of shaky premises in here and I don’t want people left thinking this is a solved problem.
First, the two proposals aren’t competing. I want to put that out there right away—the two solutions, in combination, serve to address the list of use cases we’ve outlined at http://usecases.responsiveimages.org
In terms of a “responsive image format,” a great deal of discussion around this has already taken place in the RICG. The issue is that this—like image negotiation based on bandwidth, as you mention—is also 100% in the hands of the browsers. However, there are a couple of additional catches: first, the development of this alternate format has to be funded by the vendor(s) and they have to do so while 100% willing to share this format with all other vendors, even if they’ve chosen not to pitch in. The developing vendor(s) would be left footing the bill. As you can guess, the browser reps we’ve spoken with don’t really consider this to be an option.
The other issue is that there wouldn’t be any predictable fallback. JPEG2000 has still seen little-to-no adoption and can’t reliably be used today, but when chucked into an `img` tag it will still be requested by the browser. Then we’re left with the issue of providing a fallback, after that wasted initial request—we can’t exactly feature-detect for an image format. We’d have the option of doing content negotiation on the server-side, based on UA detection, but that’s about all. It should be noted that a part of the `picture` proposal is that each `source` would accept a `type` attribute, allowing UAs to skip over sources of unrecognized types, for this exact reason.
We regards to art direction not belonging in markup: it’s a markup issue as much as the size and cropping of any content images are—otherwise we’d be using the same size images for everything and managing it with CSS. Don’t get hung up on the “art direction” name; this isn’t stylistic so much as a matter of ensuring that the content being delivered is appropriate to the user’s context.
Implementation-wise, too, it wouldn’t be a matter of adding a quick cropping feature in CSS—not on a production-scale site, unless you knew the primary subject matter would always be in a certain part of the image. At best, you could hope to create a custom CSS framework where you’re relying on scaling and `overflow: hidden` to focus on (still pre-determined) parts of the image. You’d end up with an inflexible art direction system that still forces users to download a larger image than they’ll potentially need.
I agree that responsive images aren’t much of an issue in the multi-column wireframes you’ve posted, but those designs may not be a good fit for what’s being proposed—the idea is not that you’d be required to use this in every case where images are being resized, but rather in the case of large “hero” images—the Boston Globe’s Magazine page was what started us down this path, and still serves as a great example. Further, the size of the containing element isn’t an unknown, and we don’t need the image to be aware of it any more that other parts of our layout have to be inherently aware of their containing element’s size. It’s up to the designer/developer to choose image sources that are appropriate to that part of the layout.
Re: not living with the problem long enough—I assure you, many of us have. This has, with no exaggeration, been my unpaid part-time job for the better part of a year now. Of course there are flaws with the proposed standardize solutions to this issue, but many much, much smarter people than I have been working on solving this for a very long time now. If it were a matter of just having a “eureka” moment, I doubt we’d be where we are now. In the meantime—my full-time job—I’ve been using Picturefill (which mimics the proposed markup pattern) on day-to-day client work. I’ve had great luck with it so far.
I want this to be done and solved more than anyone; I do. I’m doing the best I can, and the other members of the RICG are working just as hard on this—and harder, in many cases. But this isn’t solved, and nebulous statements like “we just need a new image format” or “let’s just come up with something better” don’t get us any closer to a solution. If a better solution were to come along, that would be the end of it. If anyone reading this should have one, I welcome it like you would not believe.
Not doing anything about this problem, however, is not something I consider an option. It smacks of perfect solution fallacy, and passing on an option because it isn’t perfect means failing our users for the sake of theoretical purity. I’m not willing to do that; nobody should be.
I urge anyone who finds themselves interested in this subject take the time to familiarize themselves with the work being done by the Responsive Images Community Group, and read through the prior discussion at http://lists.w3.org/Archives/Public/public-respimg/, http://www.w3.org/community/respimg/, and http://lists.w3.org/Archives/Public/public-html/
Join us, and help us solve this.