There seems to be a problem with the way favicons (http://en.wikipedia.org/wiki/Favicon) are currently used.
The collective will of the Dark XML Lords speaks thus: YOU ARE A POOR PAWN FOR OUR WORLD DOMINATION PLANS. BEGONE.
The whole concept of favicons is utter shit.
>>3
Care to elaborate?
I, for one, think favicons are a great way to instantly see what web sites are opened in a browser, to identify links and to organize bookmarks.
Yeah, I wasn't fond of the idea at first but they really do add a lot usability-wise, especially when you have many tabs open.
I really wouldn't mind seeing some serious discussion on this (yeah, I know, I know). Favicon HTTP header.. why not?
Most website owners don't know how to set up a http header. Making a favicon is already enough of a pain for non-technical people, having them to configure their .htaccess would just make it even worse.
Also, what about robots.txt ? Would you also recommend a X-Robots-exclusion-file: /robots.txt ? Doesn't it work well enough right now?
>>6
non-technical people should stay the fuck away from computers.
>>7
Unrelated to the topic at hand, but that's a good excuse for sloppy UI design, which affects everyone.
It'd have economic impacts as well, but I hope I don't need to state the obvious.
>>6
Implementing the HTTP header method wouldn't require the existing alternatives to be dropped.
Every new feature makes "matters" more complicated. That hasn't stopped huge amounts of bells and whistles from being added to XML and CSS (I wish it would).
Hmm, if browsers sent a referrer URL for their favicon.ico requests, I could use a temporary redirect based on it. They don't, though.
But there MIGHT be a good reason not to do things this way. I'm just saying "Adding the feature at all complicates things" isn't that reason. Please, attack my proposal on other fronts.
>>10
The header could just take precedence over /favico.ico
>>12
I was not really discussing whether or not it should be done that way. Of course a fixed location isn't the best way to go. It's just that on the web, huge problems can take years to get fixed, so nobody will ever care about something that is merely inelegant if that thing already works. That's why I think there's no way this proposal would get any support.
>>14
Is it really that hard to get a patch into Firefox?
Rather than focusing on the favicon, I would like to suggest that there is more site-level metadata than merely a tiny little icon, and thus something like the sitemaps standard should be extended to add the notion of a favicon, and then a header be introduced to refer to the sitemap.
>>16
Now we're talking! BTW: Sitemaps standard?
Or perhaps we're overengineering?
Well, the rest of the web is incredibly overengineered too, so I guess it'd fit right in.
I'm not sure if having sitemap + one header (as >>16 suggested) is better than having several headers.
Are headers supposed to be used sparingly?
>>19
a reference to a sitemap is a lot less wasted bandwidth than the content of the sitemap.
RFC2068 19.6.2.4 says that this should already work:
>>21
Innnnnnteresting. BTW, you aren't saying that IE supports it, are you?
>>22
he's probably saying he didn't even try it in IE because no one with more than half a brain cell uses IE anymore.
>>17
Sitemaps standard: http://sitemaps.org/
It's used by Google for finding every link in a site along with how often they are updated... a nice, centralised listing. In theory it replaces robots.txt although they recommend using both (at least until everyone uses the new one anyway.)
>>24
That standard seems to break niceley with dynamic sites (Unless one feels that regenerating a file the size of a few megabytes everytime something changes is a good idea).
If I remember correctly, the sitemaps standard allows you to break up a sitemap among multiple files, so that changing a relatively 'volatile' location within it doesn't require rewriting the entire thing.
They're important for usability when you have many tabs open. And if they're worth doing, they're worth doing right.
Doesn't help for multiple tabs in some browsers.
On the other hand, meaningful page titles ARE important for usability when you have many tabs open.
> Other browsers put them in the tabs, or address bar, or even in the window-icon so you can find that web-application in your alt-tab list.
If you have sixty windows open, you would prefer 60 blue e's floating in a scrollable alt-tab box?
>>30
One can overlay two icons. Bigish app icon, with the favicon in a corner, smallish. It works great (Konqueror does this). What would be neat is if there was some indication of how many tabs any given browser window does have open, but that might be possible with some title bar magic, I dunno.
>>32 Hey now that's a clever idea. Perhaps superimposing the tab-icons as sigils around the browser icon would work well so long as the alt-tab icon was big enough.
>>31
Who the hell has 60 windows open? Tabbed browsing wasn't invented yesterday.
>>34
Some people leave tabbing to the window manager. It's a fair approach, really -- doesn't require the application to lift a finger.
>>35
I think that's the right approach; but until the popular window managers implement it, they're going to be implemented in each program instead.
Emerald supports it, and is quickly becoming a default for many GNOME users.
Finally, window managers with tabs. I noticed a few years ago that every program under the sun was implementing tabs itself...