Although Firefox is a great browser that protects users from pop-ups, spyware and should replace IE it does have a big issue.
favicon.ico
Firefox by default wont find favicon.ico by reading a HTML/XHTML document and looking for a <link rel> pointing towards it, instead it will play a guessing game and think that its located in the same folder as the document being requested. The result? My error log files are getting too fucking built up with firefox browsers crawling for a file that isnt there. Now at first thats not a big problem, but when my weekly log files show 250,000 requests average, the 404 error requests for favicon.ico are a bit too much, especially when im checking logs for REAL errors.
So, here is my solution.
The result? Not a significant reduction with user interaction, but it saves site admins like me having to cull out favicon 404 errors. I should not have to have an ico file in EVERY FOLDER, or clean out my error logs constantly as a result of letting firefox users view my sites.
Anyone got thoughts about this? If I get around to it, I may just suggest this to Mozilla or someone who cares.
Deflate is generally better than LZW, so for most images PNG will be smaller unless you hit a corner case. I believe GIMP has a decent compressor, but I'm not certain.
Mind you, you're right about PNG overhead. IIRC, a single-pixel GIF is 31 bytes, while the same PNG would be 60-70 bytes. So maybe GIF would be a better choice for something so small after all.
Can anyone comment on MNG? It sounded good, but I heard somewhere it turned into a huge hairball.
>Often I'm able to make a smaller GIF than a PNG out of the same image. It might be because PNG is cramming in more metadata, or maybe The GIMP's PNG compressor just sucks.
or perhaps you're not converting the image to indexed mode (Image > Mode > Indexed...) before saving it?
same image (320x320, random data):
test.png: 101 KB (103,993 bytes)
test.gif: 137 KB (141,195 bytes)
My opinion: too little too late too big too featureless.
What people wanted was a quick replacement for GIF. They got a bunch of monsters instead. PNG. MNG. JNG. Alpha transparency. 32-bit. Who wanted all that?
"At the time of this writing (1997), the MNG specification has undergone some 31 drafts--almost entirely written by Glenn Randers-Pehrson--and seems fairly close to being frozen" www.libpng.org/pub/png/pnghist.html
I remember back then trying to convince Glenn to add .ECC features like a script (only one pic stored and it could be played several times) but he didn't want to make MNG too complex. Well, maybe he was right, but...
Meanwhile no working MNG creation library in sight for years. PaintShopPro was the first to come out with a working model, but the files, being 24/32 bits, were huge. No way this could go on the internet. And basically only PSP could read those MNGs. Other MNG players would have limited degrees of success playing these back.
The main failure of MNG IMO is that it didn't take bandwidth in account. No real effort was made to save space. And back in the day, playing back images at 24bit was SLOW.
There should have been a MNG8, a direct clone of GIF with just the LZW replaced. But no, they had to make it "perfect". That alpha crap may be perfect but in practice it's a pain. Browsers had a hard time with it, and probably still have. Currently it's basically only used at 2chan to play pranks with PNGs, a pic of a pretty girl thumbnail becomes another pic when viewed in full. Whee.
Meanwhile, the patent on GIF expired. Bye bye MNG.
.ico supports 24 bit colour just fine. Also, for a 16x16 image, compression really isn't very important these days. We're talking 1kb files. This is an order of magnitude less than your average index.html.
Of course, using standard formats is a better idea in general, but since the <link> format for favicons doesn't care what format the favicon is in or what its name is, it's a moot point. Reading /favicon.ico is a backwards-compatibility kludge anyway, so it's not like anyone's going to do any work to improve it.
>>27
I did a bit of reading, and it seems they're now playing with APNG, essentially a quick hack on PNG that gives animation much akin to GIF. Supports an actual alpha channel too. My only regret is it doesn't support compression of deltas between frames.
Pity about MNG. There were some neat tricks in there.
>APNG
Looks interesting. But not yet what I had in mind, the possibility of reusing older frames.
DISPOSE_PREVIOUS seems interesting. There was something I wanted from GIF, Background/Sprite Frame Flags. The Background frame would be always be redrawn, and Sprite frames playing over it. Maybe DISPOSE_PREVIOUS can do that, by always reverting the scene to the previous one. Tho, the first frame would be an empty background... it would end up blinking. No good.
My Background Frame Flag would have been "don't display this frame until the next".
>>27: I love PNG's alpha channel capabilities, as well ad the 32-bit-ness (if I need it). They're just kind of hard to work with sometimes because fucking Internet Fucktard Assplorer, which is very gay, breaks it.
>>26: Could you post the test image in question somewhere in an uncompressed format (BMP or TIFF)? What program did you use in your test?
MNG supported objects like that. APNG is more or less a PNG counterpart to GIF's animation, and only a little less limited.
One problem with the spec is it doesn't clearly specify behaviour between frames. Ie, DISPOSE_PREVIOUS could work just fine if the decoder only diplayed finalized frames. I suspect in this case that what you want to do is actually possible, and was intended. There isn't that much use for a DISPOSE_PREVIOUS flag otherwise.
I concur with >>31 (and I also curse IE under my breath).
What I'd enjoy having is an image format that allows some parts to be lossless and others to be lossy. Ie, cut an image into 16x16 blocks, passing some blocks off to jpeg and the rest to png, possibly throwing in a lossless alpha channel on top.
I heard somewhere once that it might be possible to combine JBIG and JPEG in such a way, minus the alpha channel, but I have my doubts.
Wow, what a way to sidetrack a thread. Good work fellas.
What's wrong with a discussion meandering?
>>35
Where is the sidetrack? We are still talking about browsers and stuff.
>>34
It depends on the content of the image.
Sometimes GIF wins, sometimes it's PNG.
If the image had uniform, gradient colors, PNG wins.
>>31
There has been a lot of broken implementations.
I recall Quicktime taking over the .PNG extension in all my browsers without asking me, and no way out. No uninstall. Problem was, QT version of PNG was broken in more ways than one. That's when I swore to never install Quicktime ever again.
Then, I seem to recall it took a while before Netscape caught on. Is it flawless now? And the others? Does it work under Opera?
> [Firefox] will GET /favicon.ico without being told there is one.
Download managers and spiders will look for robots.txt, isn't it similar to that?
>I recall Quicktime taking over the .PNG extension in all my browsers without asking me, and no way out. No uninstall. Problem was, QT version of PNG was broken in more ways than one. That's when I swore to never install Quicktime ever again.
A late relief for QT-related PNG / MP3 (another common victim of QT) disasters is throwing out all mime-type associations in the "browser plug-in" tab, and then doing the same in the "file type association" tab ON INSTALL.
>>39
It's worked flawlessly in Opera from at least 6.03. Perhaps even longer, I can't recall. It did work in some form from 3.0 on.
Going back, PNG has worked properly in ACDSee since at least 1997 too. I'd be surprised if it didn't work properly in most implementations. Well, except for IE, which by default has somewhat broken alpha.
There has been also discrepancies between image editors.
A PNG in Photoshop looked different than the same image in PSP. Something to do with PSP never showing the alpha and PS showing it always. PNGs created by PS were bloated so I always had to resave them under PSP, that's where I noticed it.
Amusing (or maybe not so amusing) fact: Painter never supported the PNG format.
And PSP always stripped out the alpha when saving, I believe. That washed-out look was always gone after a resave.
Three image editors, three broken PNG support.
I loved PNG for its compact size but I never got to use its alpha.
Ah. I have a pet peeve with Adobe's products in that regard. You'd expect that the world's premier raster/vector/layout/etc editors would flawlessly handle images they support. Hah, how naive of me!
Whenever I save a PNG in PS I always have to crush it. I've found advpng to be better than pngcrush in general, but both preserve alpha. Generally I get about 20% savings over PS.
The visual differences you were noticing though, are you sure that wasn't due to color profiles and gamma?
>>40
robots.txt usually apply for the whole site so a single request by a bot is all there is at. Bot also usually don't pound the server with requests for robots.txt for a short period of time.
Here is a ridiculously-exhaustive list of browsers that support PNG, and the level to which they do so: (Did you know the Dreamcast browser supports the PNG alpha channel better than IE does?)
http://www.libpng.org/pub/png/pngapbr.html
Lists of other programs (image editors and others) that support PNG can be found through the links at the bottom of that page.
>>34: I may have forgot to convert the image to indexed color. To tell the truth, it's been a while since I tried. I'll be sure to keep it in mind when I try it in the future.
robots.txt is exactly for that, crawlers like Googlebot. Its not designed for end-users' software to get a "ruling" on where, and where not to go. It's to prevent web spiders trying to dig around in links where webmasters would prefer not a search engine to find out.
>>44
Yeah - Adobe bad boy.
Looking at PS from the link Albright provided, I see that it's even worse than I imagined.
I used to use pngcrush, but PSP v5 has a pretty good compression level already. Dunno about later PSPs - I don't like the new design - but I suppose it's as good. I'm not going to bother using a command line for a couple of 100k on a very large image.
Ah yeah, maybe it was gamma. I never use that gamma stuff either anyway.
Quick note about PNG files and why saving them sucks in Photoshop, PSP, etc.
Gimp, and lots of other free software tools (including Moz/Firefox) all use the libpng library. It is the reference implementation. GIMP I think does some pngcrush-like tricks before saving too. (pngcrush uses libpng too, it just knows how to use it the best)
Meanwhile Photoshop, IE, PSP and the others all have native implementations which function at different levels of compatibility and are just a bit less sophisticated. Because PNG isn't quite as popular, they've settled for "at least it works so we can list it on the box" functionality.
And it's unfortunate that the gamma chunk is actually interpreted by the browser when you can't also set the gamma for any other part of a page.
You could always omit the gamma chunk if you feel it will mess up your color matching.
I use iGrafx Picture Publisher 9 to save PNGs. Worked pretty fine for me so far.
>>47
The point was that it's requesting an unreferenced file, so there's a precedent for doing that.
> I should not have to have an ico file in EVERY FOLDER
Hmm. True. Maybe in addition to the first and third points in >>13:
If no icon is specified by <link>, Firefox should only look for favicon.ico in the top directory of the domain.
Is that an appropriate compromise?
Apologies for the late reply. I feel a browser should not be "looking" for a file unless it was linked to it through the HTML (ie <img>, <link rel> etc etc) or if the user requested it. That's the way I feel a browser should operate, and webmasters shouldnt have to insert any file into one or every folder just to satisfy the demands of one browser. If the designer doesnt provide an icon, for whatever reason (and this reason could be more than "dont care"), a browser shouldnt have to poke around trying to find something that is not suppose to be used.
Another compromise would be BETTER CACHING of icons for a site. However that leads to other problems when you have multiple pages with different icons on the same site.
The caching is, as I've mentioned, very aggressive, and you have to go to great lengths to get Firefox to re-read a changed favicon. HOWEVER, there is no caching for non-existent icons, which is the real problem here. Nobody would be complaining if Firefox just checked for the icon once, and then didn't check again for a few weeks.
>>53 Admins wouldnt complain because the number of favicon.ico requests would be low, but the webdesigners who try to do fancy thing with favicon.ico will. But boo-hoo to that.
> webdesigners who try to do fancy thing with favicon.ico
can't they use <link rel> to change it?
Signed.
Except, I don't think there should be a compromise: if the HTML doesn't reference it, why the fuck are you GET'ing it?
Why are you treating data communications protocols as some sort of religious dogma? You get it because it's convenient to the users and the web designers. That's it. There's no divine law that says that a file has to be referenced in a HTML document before you can get try to access it.
>>56
It doesn't look like it's going to be disabled, and it does have some use. Best you can hope for is that it behaves politely.
Paint Shop Pro has handled PNG alpha transparency since at least version 6 or 7. When you initially load a PNG into it, it does not load the alpha channel. If you want the alpha then load it into a mask. Also, by default, PSP is configured to save PNGs without an alpha channel. Choose options when saving to PNG and then run the optomiser. From here you can switch on saving of transparency to the alpha channel. The settings in the optomiser should be retained for the next time you save a PNG.
It's not as nice as it could be, but it works.
Going back to the original topic. I don't like that it gets favicon.ico without being asked to, but I suppose it is the only way to display icons for files that cannot link to it, such as images. It is however, very bad form that they don't cache the 404. Worse still is the fact that they still look for it even when an alternative has been specified in the document that was requested. That is undeniably a bug because no one needs more than one icon.
Personally I'm inclined to say that it should look for the favicon.ico only for files that cannot contain links to it. For an HTML document that does not contain a link, it should not look. Web developers should not be allowed to be lazy or what you end up with is the horrible mess that the web was 3 or 4 years ago, and is still recovering from.
>the horrible mess that the web was 3 or 4 years ago
"the horrible mess that the web has always been"
Fixed.
pwned
>>52
The problem with this is that icons for things like bookmarks won't be able to be displayed unless their data is retrieved. Yet a user at http://example.org/~bob/hosted/www.site.com/me/ won't want example.org's root favicon.ico loading for his page, so he puts it in every directory he wants it to apply to. He couldn't just put it at the root of his site because the browser wouldn't be able to tell at which directory the parent site stops and his site starts. The difference between IE and Mozilla/Firefox in this regard is that the open-source nature of Moz. allowed web designers to scratch this itch by adding checks for this.
orz ... s/what now/what/
One solution is to use Gimp to draw up a quick 16x16 image and save it as favicon.ico (gimp 2 can save winders icons).
Then, create a symlink to /web-root/favicon.ico in all the subdirectories. Since the symlink and target file will both be within the Web tree, any server ought to return the same favicon to everyone. (This of course assumes you're using a Unix or Linux server. I don't know if it's even possible on a Windows server.)
>>66
In NTFS, you can create hard links for files and symbolic links for directories and drives, and there may be a way to do symbolic linking of files in Apache.
Does firefox cache 301 (moved permanently)? If so, you could config apache to just return 301 (to /favicon.ico, or to mozilla.org/favicon.ico or whatever floats your boat) for any files called favicon.ico, anywhere in your heirarchy.
How about a cache of favicons that distinguishes between "have not checked" and "checked, but not found"? The first time you look in the cache for arr.com, you will get "have not checked", so you look, find nothing, update the cache. The next time you visit a page on the site, you hit the cache for "nothing there", so you don't check again for some long period of time. (Hmm, I like that solution. Maybe some day I'll be motivated enough to try coding it - I use Galeon.)
Toss in a rewriterule to make it redirect to nothing, thus preventing it from hitting your error logs.
Just modify your webserver not to log image requests. Or if thats too much, just those with extension .ico
Stop whining.
Somehow I think senseless requests holding up server processes isn't just whining.
It's trivial, but it's still annoying.
It's also a waste of bandwidth. Assume there are 70 million firefox users, and they each visit 3 domains without favicons a day. 210 million requests (say 70 bytes with HTTP 1.1), 210 million 404s. Call the 404 response 300 bytes on average (though some hosts will generate larger). 210M * 70 + 210M * 500 is about 80GB a day. Not huge in terms of total Internet traffic, but come on.
(How big is the average 404 message? Apache defaults generate about 300 bytes. IIS' default 404 is more like 1600. Still, more hosts probably generate smaller 404s than larger.)
This was fixed, apparently.