RSS

Blog

Favicon pet peeve

h38 Mar 2010 –  Comments (3)

Comments

Using link rel=icon on your page you can direct the browsers to the right file. So yes, you're crazy. A large part of the web is built on hacks. Bots browsing your site to build search machine indexes. Browsers that do all kind of weird things to implement some feature that the designers of the web never dreamt of. It's just the way it is.

[] me ~ 1 year, 11 months ago at 4:36 p.m.

The only problem with this is that it causes an extra hit to Django, which may not be desired.

There are two other ways around it that don't require going through Django.

  1. Change where your favicon is loaded in the section of the page. This seems to work for most new browsers.
  1. Setup an alias in apache conf (or your webserver of choice). This has the advantage of working no matter what browser/bot requests the page.

Alias /favicon.ico "/media/img/favicon.ico"

[] Tim ~ 1 year, 11 months ago at 4:37 p.m.

Using link rel=icon on your page you can direct the browsers to the right file. So yes, you're crazy.

You didn't get my point at all. What if I don't want a favicon ? I get a 404 hit anyway, it shouldn't be like this.

A large part of the web is built on hacks. Bots browsing your site to build search machine indexes. Browsers that do all kind of weird things to implement some feature that the designers of the web never dreamt of. It's just the way it is.

What the fuck are you talking about ? I'm talking about a very specific browser behavior and you talk about crawlers ? What's the point ?

And FYI:

A second method for specifying a favicon relies on using a predefined URI to identify the image: "/favicon", which is relative to the server root. This method works because some browsers have been programmed to look for favicons using that URI. This approach is inconsistent with some principles of Web architecture and is being discussed by W3C's Technical Architecture Group (TAG) as their issue siteData-36. To summarize the issue: The Web architecture authorizes site managers to manage their URI space (for a given domain name) as they see fit. Conventions that do not represent community agreement and that reduce the options available to a site manager do not scale and may lead to conflict (since there is no well-known list of these predefined URIs). One practical consideration illustrates the problem: many users have Web sites even though they do not have their own domain name. These users cannot specify favicons using the second method if they cannot write to the server root. However, they can use method one to specify a favicon since it is more flexible and does not constrain the site manager to use a single favicon at a single place on the site.

There are a few other well-known encroachments on URI space, including the "robots.txt" file and the location of a P3P privacy policy. The Technical Architecture Group is exploring alternatives that do not impinge on URI space without license.

http://www.w3.org/2005/10/howto-favicon

I AM NOT CRAZY. (thanks to a random guy on reddit for the link.)

[] h3 ~ 1 year, 11 months ago at 8:20 p.m.

Copyrighted stuff .. u know.