When requesting a file for <img> elements Safari sends "Accept: */*", which means that by default Apache will send 8-bit GIF files in preference to 24-bit files in other formats, as the GIFs are smaller. All other browsers send a preference list, with GIFs given a low q-value. A knowledgeable webmaster can set the quality of the GIF images on the server end to something less than that of the others, but many will not. I have set up the above URL to demonstrate this. Check it in Firefox and Safari and compare the last image.
See also: bug 9572 (not a duplicate). Nick, could you please post exact Accept strings from other browsers here, and maybe suggest what WebKit should send?
With all relavent prefs reset to their defaults, and my AppleLanguages = ("en-GB", "en-AU", "en-CA", fr) Strings are User-Agent, Accept, Accept-Language, Accept-Charset, Accept-Encoding Retrieving a URL given in the Address Bar: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/420+ (KHTML, like Gecko) Safari/417.9.3 */* en-us - gzip, deflate Opera/9.00 (Macintosh; PPC Mac OS X; U; en) text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 en iso-8859-1, utf-8, utf-16, *;q=0.1 deflate, gzip, x-gzip, identity, *;q=0 Mozilla/5.0 (compatible; iCab 3.0.2; Macintosh; U; PPC Mac OS X) image/png;q=0.7, image/jpeg;q=0.6, image/pjpeg;q=0.6, image/gif;q=0.5, image/x-xbitmap;q=0.4, image/xbm;q=0.4, text/html;q=0.9, application/xhtml+xml;q=0.7, text/plain;q=0.6, */*;q=0.1 en, *;q=0.5 utf-8;q=0.9, utf-16;q=0.5, utf-7;q=0.2, ISO-8859-1;q=0.7, *;q=0.6 - Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/125.4 (KHTML, like Gecko, Safari) OmniWeb/v563.66 image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, image/tiff, multipart/x-mixed-replace, */*;q=0.1 en-gb, en-au;q=0.8, en-ca;q=0.6, fr;q=0.4 iso-8859-1, utf-8, iso-10646-ucs-2, macintosh, windows-1252, * bzip2, gzip, deflate, identity Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4" application/xhtml+xml, text/html; q=0.9, text/plain; q=0.8, image/png, */*; q=0.1 en-gb,en;q=0.5 UTF-8,* gzip, deflate Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) */* en-gb - gzip, deflate All browsers send the same string at other times too, except Firefox and WinIE, which also send: When retrieving a document via an <img> tag with no type: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 image/png,*/*;q=0.5 en-gb,en;q=0.5 UTF-8,* gzip, deflate Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */* en-gb - gzip, deflate When retrieving a document referenced via a <link rel="stylesheet" type="text/css"> tag: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 text/css,*/*;q=0.1 en-gb,en;q=0.5 UTF-8,* gzip, deflate When retrieving a document via a <script type="text/javascript"> tag: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 */* en-gb,en;q=0.5 UTF-8,* gzip, deflate
This could be important with HiDPI and multi-representation tiffs or JPEG 2000 files...
Preferring PNG over GIF can break color consistency - see <http://hsivonen.iki.fi/png-gamma/> for a long sad story. WebKit renders most PNGs differently from Firefox (only ones without any color space information at all look the same).
Well that's rather irrelevant, because (a) it'll get fixed, and (b) GIF doesn't do colour correction anyway.
> (b) GIF doesn't do colour correction anyway. This is exactly why it is better for compatibility (please read the provided link). The issue with PNG gamma/color correction is a well known problem, I certainly wouldn't denounce it as irrelevant.