First off, I'm not 100% sure I'm filing the bug in the right place. If I am not, please tell me where to file it. I read on the Firefox bug regarding WebP [1] that web developers would love to use WebP, but can't because Firefox doesn't support it. Server-driven negociation could be a way out. It's been suggested elsewhere [2] that the current HTTP Accept header for images (*/*) in Chrome and Safari is useless when it comes to server-driven negociation. What about improving it so that it reflects the capabilities of the web browser? Specifically, if the browser handles WebP, the header could say so. This way, servers could implement server-driven negociation based on an actual header. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=600919 [2] http://www.igvita.com/2012/12/18/deploying-new-image-formats-on-the-web/
More complains about the unhelpful Accept header: http://www.webmonkey.com/2012/12/forget-javascript-its-time-for-browsers-to-speed-up-images/
(In reply to comment #0) > It's been suggested elsewhere [2] that the current HTTP Accept header for images (*/*) in Chrome and Safari is useless when it comes to server-driven negociation. From the article: "Chrome and Safari headers are effectively useless - we accept everything!" At least in Safari's case we accept everything because... well... we support everything that can be opened on the system. "Opera is the only one explicitly enumerating the supported filetypes, which is the behavior we want..." ...And the list of types Opera claims to support is much smaller than the list of types Safari on Mac actually supports. If we were to actually enumerate all types we actually support we'd have request headers much, much larger than average and slow down page loads. I've retitled the bug to: "Make HTTP Accept header for images useful without slowing down page load speeds and without using excessive bandwidth" ...to specify what an acceptable resolution to it would be.
(In reply to comment #2) > If we were to actually enumerate all types we actually support we'd have request headers much, much larger than average and slow down page loads. > > I've retitled the bug to: > "Make HTTP Accept header for images useful without slowing down page load speeds and without using excessive bandwidth" > ...to specify what an acceptable resolution to it would be. I fully agree. I've discussed the matter on the Firefox side [1] (the bug has changed of summary over there too for the same reason). A couple of conclusions I've drawn from all this Accept-in-<img> discussion: * No need to advertise image formats which are known to be widely supported (jpeg, gif, png) * No need to advertise bad or too exotic image formats even if actually supported * Accept can be a good idea in transition period when a new good format come along. * Even when doing server-driven negotiation, a webdev has to test the website, so server-driven negotiation shouldn't be expected to be a magic fully automated thing. * Web browsers are reluctant to change their Accept, because it may break websites. In the end, I think it might be good to advertise for image/png, image/svg+xml (debatable) and image/webp (if supported) I'm also coming to the conclusion that Webdevs could work around the problem of browser-wise Accept by sending themselves HTTP requests via XMLHttpRequest with their own Accept. The matter could be solved in probably about 30-50 lines of client-side JS. I might just write a library, benchmark and if I'm happy with the result, tell people to do that. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=824623