All modern web browsers support PNG images and content negotiation doesn't happen in the real world, so we should shrink the accept header by not explicitly naming "image/png".
> All modern web browsers support PNG images Is this really true? Even embedded browsers etc.? Also, removing PNG means that we are now saying that we equally prefer PNGs and GIFs (because PNG falls into */*). Is that something we want to say? > content negotiation doesn't happen in the real world It certainly won't if our Accept: header ends up the same as IE's "*/*", which is where it seems to be going. Gerv
Comment on attachment 146980 [details] [diff] [review] remove image/png yeah, i don't like this patch. i think there is value in advertizing support for PNG. this is not the same as when we eliminated GIF and JPEG.
Comment on attachment 146980 [details] [diff] [review] remove image/png I don't really know the details of how this header works, but removing this request until you guys get it resolved.
(In reply to comment #0) > All modern web browsers support PNG images and content negotiation > doesn't happen in the real world, so we should shrink the accept > header by not explicitly naming "image/png". IMHO it should be extended, at least when requesting a image in imageLoader.cpp: "image/*" should be in front of "*/*" and btw. content negotiation happens in the real world! Yours Joerg
Is this WONTFIX? We should prefer PNG over GIF in my humble opinion. (And perhaps SVG over PNG when we have support for that (and enabled).)
I agree with Gerv and Joerg. If I have the following resource: /photo/3 And that resource has two representations: text/html image/jpg What I would like to do is, have the text/html version be this: <a href="2">Previous</a> | <a href="4">Next</a><br> <img src=""> So when I browse to a photo with the browser, it will show the HTML representation with navigation links, which then loads the JPEG representation inside it. Maybe also a title. If the Accept header for images would have contained image/*, then this would have worked. However, currently, the HTML representation is chosen over the image, because both are part of */*. So I couldn’t get this to work. Sending the following accept header would be an improvement over the current one: Accept: image/png,image/*;q=0.8,*/*;q=0.5 As for image/png, it’s true that the usefulness is a bit limited now that IE7 supports PNGs fully and IE6 partially. However I think there are still a number of mobile browsers that do not support PNG, and thus it is probably still useful to indicate explicit support for PNGs. But, this is only useful if PNG-supporting mobile browsers generally do this as well. By the way, if your argument is that content negotiation is doomed and is and will never be used (I kindly disagree :)), then you should want to remove the Accept header entirely, and not just parts of it. ~Grauw
I created bug 398066 for having image/* in the Accept header, according to comment #8 and comment #6.
-1 Content negotiation is very useful in the real world. It won't be if you castrate the UAs
The default header is now : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Firefox uses different Accept headers depending on fetching resource types. It still uses "image/png,image/*;q=0.8,*/*;q=0.5" for images.
I'm against this. I still prefer a png to a gif image.