There seems to be a problem with the way favicons (http://en.wikipedia.org/wiki/Favicon) are currently used.
The ideal way seems to be to send an HTTP header pointing to the favicon URL associated with the resource. "X-Favicon: /favicon.ico".
I did a quick search for favicon "http header" to see who had come up with this idea before me and why it wasn't used. I found nothing, no instances of this solution being proposed. I'm stunned. Is this so revolutionary not to have occurred to anyone?
4-ch, what do you think?
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.
Honestly, I think this feature (unlike many in HTTP and HTML) has enough use to justify the quite small complication of implementing it. It'd mean, what, 100 lines of code at worst? Less if implemented in a browser that was well-designed and not bloated, but I'm thinking Firefox etc.
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.
If there were a proposal made by a serious industry coalition (including Microsoft) for an improved icon standard (Maybe associated to some sort of website description microfomat metadata semantic web 3.0 thingie), it could get fixed, but only as a replacement for favicons.
>>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.
This way in the future, when someone wants one more thing in there, it doesn't mean sending two headers.
>>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:
Link: <http://example.com/icons/fish.ico>; rel=iconbut neither Firefox nor Opera support it.
>>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.)
>>19
It's true that sitemaps can be large, but the number of hits a person makes on your site can also be large -- remember, the OP was suggesting that every single file on your site gets this new header... that means all images, all javascripts, all stylesheets... this will add up as they visit it more and more, whereas you only need to fetch the sitemap once, and you only need to fetch the favicon as often as the sitemap file tells you to (it might say "this favicon refreshes once every year.")
>>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.
And to OP, favicons are pretty, and clients like it when you give them one, but they're redundant. The purpose is to give someone a visual clue as to what site they're on, but the design of the site itself should be able to do that.
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.
They aren't mutually exclusive.
Favicons aren't to give people a visual clue as to which site they are on, they are designed to be icons for your favorites list which is stupid: 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. Some web-application applications take advantage of this and animate the favicon so that people can know that a application desires attention. Others use the icon to indicate a logged-in or session state. This means that the favicon has become an additional graphic feedback mechanism.
> 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.
Wow, talk about bad application design. If you did that, you would NEVER know what icon your browser was when you're searching for it in alt-tab. You would have to remember the icons for every site you will ever use, and which browser you opened them in most recently.
If you have sixty windows open, you would prefer 60 blue e's floating in a scrollable alt-tab box?
Having the page-icon be presented in the window list means it is easier to spot a particular web page, not harder.
>>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...