Ico

[Twey]

Requiring it to be /favicon.ico is simply daft. Not only does it cause problems for people whose sites are a subdirectory of a domain (and that's not only people who don't own a domain of their own), it also introduces difficulties for those who would rather have a favicon that isn't global to their whole site — to give one area of the site a different favicon from the rest, perhaps, or mayhap they'd rather give each page its own favicon to identify it at a glance (this presumably being the original intention of a 'favourites icon').

[jscheuer1]

Agreed. Did I say anything that wouldn't support those uses? If so, I wasn't being very clear. I just think that in the absence of a link rel="ico" tag, it should default to the /favicon.ext convention if such a file exists. And I believe that many browsers already work this way, and that if some of the current trends in standards compliance extend to this issue, that they will continue to. I hope others will follow.

My point is that it's equally daft to not allow the /favicon.ext convention. We can have either and/or both, can't we?

I think an argument in the past with the /favicon.ext convention may have been that browsers were pulling 404's and wasting time looking for non-existent favicons. I don't think that's much of an issue, it would be like any other missing image, just move on to the next resource.

The only real problems would be - say you have a favicon in the root, but don't want any favicon on certain pages. But then you could simply place the file elsewhere and have link rel="ico" tags for the pages you wish to have the favicon on. And the only one that couldn't be so easily resolved - say you want no favicon, but you are a sub domain of a host that has one in their root. There should be a tag to turn off favicon, perhaps a link rel="ico" tag with no href and perhaps some attribute/keyword to turn it off.

[Twey]

No, I was just airing out my soapbox according to my wont

Certainly we can have both, but the goal of a standard is to set the, well, standard, way of doing things — the high target towards which developers should be aiming. So long as they don't interfere with that standard, extra features can be added on to the developers' hearts' content, either for backward compatibility or forward-thinking innovation. If an instance of the latter class is good enough, it may make it into the standard itself one day. However, a standard cannot specify backward-compatibility, or standards would snowball in length indefinitely with each new version

Your idea of a explicit favicon-disabling tag is a good one. Have you considered suggesting it to the W3C?

Edit: To clarify the issue: the favicon is required to not be displayed in the Acid3 test because the URL, despite returning a valid image, also returns a 404 error code — not because it uses the /favicon.ico URL. The inclusion of this in the Acid3 test could even be considered tacit consent to it.

[Snookerman]

Why don't they just do as they do with the default pages. If there is an index.html file in the folder it is shown. Can't they do that for favourite icons, if there is one in the folder and there isn't one specified in the code, it will show. If the favicon is in the root folder, it should only show on pages in the root folder. That way, if someone has a subdirectory they can just place a favicon in their folder (or link to it) if they want one and not do anything if they don't want one, just like not having an index.html page in the subdirectory will not show the index page from the root (at least I think it doesn't).

[Twey]

I think that the W3C would rather opt-in than opt-out, and these 'magic defaults' that aren't specified in the page or its headers are generally considered a bad thing.

[jscheuer1]

Tongue firmly in cheek:

Many of the W3C recommendations seem intended primarily to have us typing our little digits off.

Tongue back in its proper location. (don't ask)

The fact remains that browsers will probably continue to support the /favicon.ext convention (so many pages rely upon it already), and (one would also think, given the W3C's stand on these sorts of matters) they will continue not to favor an opt out tag, as it only encourages the practice they oppose.

So I think we can look forward to a continued mess/confusion as regards /favicon.ext for some time to come.

[Snookerman]

these 'magic defaults' that aren't specified in the page or its headers are generally considered a bad thing.

Do you mean the index.ext or the favourite icons?

[Twey]

The favicons. index.ext is not a magic default at all but a conventional default for a configurable server setting: it has nothing to do with the browser.

[Snookerman]

But wouldn't it be possible to do the same thing with the favourites icon? That it would follow the same rules as the index default.

[Twey]

The favicon path is determined by the browser, not the server, so it can't be adjusted as the other defaults can unless it's indicated to the browser explicitly — via a <link>, for example.