Jump to content

Talk:Favicon: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Picture: new section
I asked what favicons are used for.
Line 89: Line 89:


Should we update the picture? '''<span style="border:2px solid #FF4747;padding-left:5px;padding-right:5px;color:#FF4747;">[[User:George8211|<font color="blue">George8211</font>]] // [[User talk:George8211|<font color="green">Give a trout a home!</font>]]</span>''' 16:22, 15 December 2013 (UTC)
Should we update the picture? '''<span style="border:2px solid #FF4747;padding-left:5px;padding-right:5px;color:#FF4747;">[[User:George8211|<font color="blue">George8211</font>]] // [[User talk:George8211|<font color="green">Give a trout a home!</font>]]</span>''' 16:22, 15 December 2013 (UTC)

==What is the purpose of favicons again?==
Since the side effect of estimating the number of visitors who have bookmarked the page no longer works, why is so much effort devoted to them?
And in my IE 10 w/ Win7, favicons are in my cookie/Temp Internet Files, but unlike cookies, they cant be deleted.
This is troubling.
Do they work like cookies as a tracking device, etc?
[[Special:Contributions/74.60.161.158|74.60.161.158]] ([[User talk:74.60.161.158|talk]]) 17:36, 11 January 2014 (UTC)

Revision as of 17:36, 11 January 2014


What exactly is the purpose of favicon.ico? For bookmarks only? Or not?

When I see that my web server has served the file "favicon.ico" to a remote machine, can I infer that the user of that remote machine has bookmarked my web-site or web-page, or is the serving of favicon.ico not a reliable indication of a book-marking on the part of the remote host? —Preceding unsigned comment added by 76.10.130.47 (talk) 17:26, 20 December 2010 (UTC)[reply]

favicon.ico is generally served with all page requests, so no, you cannot infer that your visitor has bookmarked your page. My Ubuntu (talk) 02:19, 10 April 2011 (UTC)[reply]

File Format Support

Why does this table, or actually, this entire section exist at all? 71.168.82.147 (talk) 04:58, 2 March 2011 (UTC)[reply]

Because you can see that there are differences in supporting different web browsers. Many developers are asking about animated favicons for example. mabdul 09:50, 2 March 2011 (UTC)[reply]
The section is fine, but I'm almost sure that less than 8-bit is also okay. Notably 1-bit (e.g., black & white) or 16 colors (4-bit) are relevant, for conversions from or to XPM 64 colors (6-bit) are also interesting. –89.204.153.166 (talk) 06:25, 23 June 2011 (UTC)[reply]

Coding the Favicon Into The Page

The question becomes one of how to make the browsers recognize the favicon. The text infers that if a favicon is placed in the root directory of the website in the .ICO format it will magically appear in the address bar, which is incorrect. —Preceding unsigned comment added by 71.174.7.138 (talk) 00:27, 8 March 2011 (UTC)[reply]

Actually, that's exactly what happens. These browsers automatically look for .ico file in the root of the web site's document tree and use it if it is found. HTTPd log files will show the request for this file over and over again by each user-agent that visits and requests it. --RossO (talk) 19:30, 16 August 2011 (UTC)[reply]
[example needed] what else should happen? which browser do you use? mabdul 00:43, 8 March 2011 (UTC)[reply]

What is up with the "Limitations and criticism" section?

These are some obscure complaints which aren't really about favicons at all. They boil down to "big files take a long time to download", "you can get viruses from webpages", "old browsers don't support everything", "some webhosts suck", "html-only features don't work in gopher", and "you have to put HTML on every page for it to be used on that page". How is any of this specific to favicons? Also, it's a bit of a stretch to call GData's Security Blog a "critic" - they were just highlighting a security issue they'd come across, they made no criticism of favicons in the article. —Preceding unsigned comment added by 90.155.119.41 (talk) 10:03, 28 March 2011 (UTC)[reply]

This critic is a) well referenced and b) topic related. Of course that every big file needs longer to download than a small file, but that is something like a howto/advice not to create big favicon-files.
The fact that the favicon has to be linked on every page is a design flaw(similar to css) that is not better solved by puitting the favicon in any directory (also design flaw)...
that old browser doesn't support the favicon is a fact. That this fact may not be longer vailed is another thing.
gopher support may be also not longer a vailed argument since only a (few) hundreds sites exists, but the favicon is indeed only a www feature.
the gdata blog entry with the the drive-by-download problem may be removed although this is the best place to include such a problem: The user can't change the behaviour of the web browser not accepting any favicon. This belongs not to any particular web browser but more to all web browser and since big applications always have bugs and thus normally security problems also by the drive-by-download fact.
Overall you may be right: many disadvantages and limitations aren't directly connected with the favicon, but the problem is connected by the fact of the favicon is missing, to big or by the fundamental structur chosen by the W3C/MS. mabdul 13:10, 12 April 2011 (UTC)[reply]
mabdul 13:10, 12 April 2011 (UTC)[reply]
I've removed two of the statements. 1), the issue with "big files slowing page load" is quite unlikely, considering the favicon - being no more than 32x32 pixels in common situations - isn't likely to be larger than any other image on the page; curiously, the source plugs its own "optimiser" to solve this "problem". 2), the malware concern does not explicitly state what browser the issue afflicts, though it depicts Firefox 3 in a screenshot. Firefox 3, however, does not exhibit the stated issue- HTML content in a document that the browser expects to be an image is simply not parsed, and I am not aware of any other browser that does do so.
The concern about hosts not permitting ICO files is plausible- some free webhosts do restrict file types to a few arbitrary "common" extensions, meaning that IE, which accepts only ICO format icons, cannot be supported in this (arguably uncommon) case.--CoJaBo (talk) 01:25, 2 July 2012 (UTC)[reply]

PNG

The article contained the following statement at the end of the .ico "standard" paragraph: However, other image formats like PNG offer wide browser support and advanced features like compression and color profiles. I've removed this for now, just insert it again if you think it is okay.

While that statement is not wrong it sounds like a non-neutral POV, color profiles and compression are not typically important for 16×16 icons. And .ico offers optimized BMP images for various sizes, in fact it can consist of only one 16×16 BMP for the purposes of a favicon, which won't suffer from any automatically scaling down artefacts. Other formats including PNG have no "reverse transparency" (the opposite of the background color, XOR 0xFF), while ICO hashad no opacity (only transparency, like GIF).

IMO this article isn't a good place to compare ICO with PNG, besides SVG would be more interesting. Unrelated, just because ICO is now "officially" registered this is no proper "standard", it's only a pointer to an old Windows 95 book explaining the oddities of the ICO format (at this time, the format was extended later as explained in ICO). –89.204.137.197 (talk) 07:31, 7 June 2011 (UTC)[reply]

Exactly the same POV appeared in the ICO article; I removed it there, too. Besides this article explains that the MS Vista or "better" operating systems now support PNG within ICO. –89.204.153.166 (talk) 04:21, 23 June 2011 (UTC)[reply]

It should be noted that no released Firefox version does not support the Vista version of the ICO format. (Bugzilla entry) --93.203.232.207 (talk) 23:26, 29 August 2011 (UTC)[reply]

W3C specification references

Please use direct links to relevant paragraphs in W3C specs which defines specific rel attribute value. As i currently see, spefications only defining means to extend HTML to support favicons, there is no specific definition of favicons there. Other references are for K. Dubost's non-normative articles on favicons and these pages are linking this Wikipedia article back! Thus it is not evident what this is really standardized behaviour. — Preceding unsigned comment added by 178.140.240.108 (talk) 23:19, 6 November 2011 (UTC)[reply]

new addition

I reverted a few minutes ago this edit because of mutliple reasons:

  • 'Compatibility - All browsers, including IE 5.0 support .ico format.' - this is already mentioned in the table
  • 'Avoid 404 server errors - All modern browsers (tested with Chrome 4, Firefox 3.5, IE8, Opera 10 and Safari 4) will always request a favicon.ico so it's best to always have a favicon.ico file, to avoid a "404 not found" errors.' is simply wrong: you don't get a 404 if the link rel tag is used.
  • '.ico file can hold more than one icon, no need to have multiply files for 16x16 and 48x48 icons' although this is correct, it doesn't matter! only one is displayed.
  • If you also scroll up at this talkpage, you will notice that png has also some advantages and thus this isn't clearly written from a NPOV. mabdul 11:13, 7 March 2012 (UTC)[reply]

Creating a new top-level section for "Site Icons as Program Launchers" (as in iOS home screen icons)

I agree with IlliterateSage in his/her statement that apple-touch-icon ≠ favicon. But, having said that, the overarching method of using link rel="icon" (or rel="shortcut icon" for both confuses the issue, and I think if we squirrel the discussion of apple-touch-icon away into a different article you lose valuable context, and this would also hurt discoverability.

What I would like to do is just move the "Devices" subsection to a new (top-level) section called something like "Mobile Device Support," perhaps even "Site Icons as Program Launchers" or similar. With Google Chrome's support for adding "application shortcuts" to a user's desktop, as with Fluid on OS X and now Fogger for Linux, the topic deserves some discussion of these "web app" launcher icons. They are not-the-same-as but also not-so-distinctly-different from "favicons," so I believe this discussion should stay in this (Favicon) article. Also, the HTML5 proposal deserves an expanded mention, perhaps with code samples.

My concern is regarding the etiquette of renaming sections in an article. This could break incoming links (not in an "error 404" way) though, if for some reasons someone comes in via a subsection target link. Should I be worried about that over improving the clarity of the article? --Ernstkm (talk) 01:17, 15 July 2012 (UTC)[reply]

Jus a “Thank you” for this article!

Criticism is frequent on Wikipedia Talk pages, so, to make an exception, let me say:

Thank you all for this comprehensive article! It is the best and handiest source for information about the Favicon issue which I have ever found on the web! --Roman Eisele (talk) 14:12, 31 December 2012 (UTC)[reply]

First reference is a broken link

The reference "Creating a multi-resolution favicon including transparency with the GIMP" is broken. — Preceding unsigned comment added by 184.65.99.106 (talk) 08:55, 21 May 2013 (UTC)[reply]

Blocking animated favicons?

Does anyone know a good way to block animated favicons? I've tried adding scripts in AdBlockPlus (for a favicon.ico file), but no luck. — Preceding unsigned comment added by 114.198.124.115 (talk) 08:40, 29 August 2013 (UTC)[reply]

Picture

Should we update the picture? George8211 // Give a trout a home! 16:22, 15 December 2013 (UTC)[reply]

What is the purpose of favicons again?

Since the side effect of estimating the number of visitors who have bookmarked the page no longer works, why is so much effort devoted to them? And in my IE 10 w/ Win7, favicons are in my cookie/Temp Internet Files, but unlike cookies, they cant be deleted. This is troubling. Do they work like cookies as a tracking device, etc? 74.60.161.158 (talk) 17:36, 11 January 2014 (UTC)[reply]