Re: [whatwg] apple-touch-icon
On Wed, Jul 30, 2014 at 11:13 AM, Anne van Kesteren ann...@annevk.nl wrote: That would mean http://annevankesteren.com/robots.txt cannot have an icon, unless we revive the Link header somehow, but there wasn't much interest in that. Actually, there is now, at least on Google’s side, in the context of Navigation Transitions. https://docs.google.com/a/chromium.org/document/d/17jg1RRL3RI969cLwbKBIcoGDsPwqaEdBxafGNYGwiY4/edit (read comments) https://code.google.com/p/chromium/issues/detail?id=58456#c7
Re: [whatwg] apple-touch-icon
Given that the /favicon.ico fallback is really only there for IE5/6/7 compatibility to my knowledge, and final support for the last of those realistically ended 3 months ago along with Windows XP, I'd be all for deprecating that in upcoming revisions of the standards. Vendors can then decide for themselves how long they will keep supporting it based on actual usage, as newly developed sites will all be using the more structured methods with finer grained control. It makes sense to have both the link and manifest routes, since the first saves bandwidth and a request if you don't need the added value of a manifest. The /favicon.ico fallback on the other hand just promotes laziness. As for the touch icons I'd recommend the same sane route - have a single well defined usable standard like link sizes, and allow vendors to keep supporting the crapple proprietary syntax during a transitional period as they see fit, and practical usage of it within their audience. Any syntax with a company name in there shouldn't be polluting recommendations by definition. -Original Message- From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas Sicking Sent: dinsdag 29 juli 2014 23:22 To: Anne van Kesteren Cc: WHATWG Subject: Re: [whatwg] apple-touch-icon I'd really like to avoid sticking this in specs. We already have 3 ways of adding icons, /favicon.ico, link rel=icon and link rel=manifest. That's probably about 2 too many. We shouldn't add a 4th one. Generally speaking, eventually I think manifests is what will encourage the best UX and the easiest syntax for authors. Given that both Blink and Gecko is adding support reluctantly and is planning to remove support, adding it to the spec will make this deprecation harder. At the very least, if it's added to the spec, add very clear language about it being deprecated. / Jonas On Sun, Jul 27, 2014 at 5:13 AM, Anne van Kesteren ann...@annevk.nl wrote: For link rel=icon we already define the /favicon.ico fallback. If a page lacks link rel=icon sizes we should probably also look at Apple's proprietary extension here given that it's quite widely adopted. Chrome supports it and there is some work going on in Firefox as well: https://bugzilla.mozilla.org/show_bug.cgi?id=921014 -- http://annevankesteren.nl/
Re: [whatwg] apple-touch-icon
On Wed, Jul 30, 2014 at 10:48 AM, Niels Keurentjes niels.keurent...@omines.com wrote: Given that the /favicon.ico fallback is really only there for IE5/6/7 compatibility to my knowledge, Uhm, no. It's universally supported. -- http://annevankesteren.nl/
Re: [whatwg] apple-touch-icon
- Original Message - From: Niels Keurentjes niels.keurent...@omines.com Cc: WHATWG wha...@whatwg.org Sent: Wednesday, July 30, 2014 1:48:33 AM Subject: Re: [whatwg] apple-touch-icon Given that the /favicon.ico fallback is really only there for IE5/6/7 compatibility to my knowledge… Well-known locations such as /favicon.ico also have the advantage that they work for non-document resources (e.g. PDF, audio or video). Matthew Noorenberghe
Re: [whatwg] apple-touch-icon
I'm aware of that. It became universally supported because it was the first 'de facto standard' back when IE5 introduced support for it in March 1999. Given that there are now far better and cleaner alternatives without 'magic' filenames, I don't see a reason not to deprecate it after 15 years and thus eventually save the web a LOT of failing requests on non-existing favicons. As John Mellor said Chrome is actively removing behaviour that causes unneeded 404s[1], the same wasting bandwidth and data plan argument applies here. The message to web developers should just be if you want icons, explicitly specify them, oh and while you're at it add the sizes attribute please so we can pick the right one for homescreens and the likes. [1] https://code.google.com/p/chromium/issues/detail?id=259681 -Original Message- From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren Sent: woensdag 30 juli 2014 10:52 To: Niels Keurentjes Cc: WHATWG Subject: Re: [whatwg] apple-touch-icon On Wed, Jul 30, 2014 at 10:48 AM, Niels Keurentjes niels.keurent...@omines.com wrote: Given that the /favicon.ico fallback is really only there for IE5/6/7 compatibility to my knowledge, Uhm, no. It's universally supported. -- http://annevankesteren.nl/
Re: [whatwg] apple-touch-icon
On Wed, Jul 30, 2014 at 11:02 AM, Niels Keurentjes niels.keurent...@omines.com wrote: The message to web developers should just be if you want icons, explicitly specify them. That would mean http://annevankesteren.com/robots.txt cannot have an icon, unless we revive the Link header somehow, but there wasn't much interest in that. -- http://annevankesteren.nl/
Re: [whatwg] apple-touch-icon
On Mon, Jul 28, 2014 at 4:59 PM, John Mellor joh...@google.com wrote: Chrome 30 dropped support[1] for fetching apple-touch-icon-* from well known URLs, since the 404 pages that are usually returned were consuming 3-4% of all mobile bandwidth usage[2]. We're unlikely to reverse that. Good to know – thanks! We still support apple-touch-icon-* via link rel under some circumstances (e.g. for add to homescreen), but they're deprecated[3], since we'd like authors to use the standard for this, i.e.: link rel=shortcut icon sizes=128x128 href=/favicon.png There’s no need for `shortcut` there as per the standard.
Re: [whatwg] apple-touch-icon
On 29 July 2014 12:46, Mathias Bynens mathi...@opera.com wrote: On Mon, Jul 28, 2014 at 4:59 PM, John Mellor joh...@google.com wrote: We still support apple-touch-icon-* via link rel under some circumstances (e.g. for add to homescreen), but they're deprecated[3], since we'd like authors to use the standard for this, i.e.: link rel=shortcut icon sizes=128x128 href=/favicon.png There’s no need for `shortcut` there as per the standard. Sure, it's just for compatibility with IE11 (IE 9 and 10 allow rel=icon, but only if you also specify type=image/x-icon[1]). [1]: http://blogs.msdn.com/b/ieinternals/archive/2013/09/08/internet-explorer-favicons-png-link-rel-icon-caching.aspx
Re: [whatwg] apple-touch-icon
I'd really like to avoid sticking this in specs. We already have 3 ways of adding icons, /favicon.ico, link rel=icon and link rel=manifest. That's probably about 2 too many. We shouldn't add a 4th one. Generally speaking, eventually I think manifests is what will encourage the best UX and the easiest syntax for authors. Given that both Blink and Gecko is adding support reluctantly and is planning to remove support, adding it to the spec will make this deprecation harder. At the very least, if it's added to the spec, add very clear language about it being deprecated. / Jonas On Sun, Jul 27, 2014 at 5:13 AM, Anne van Kesteren ann...@annevk.nl wrote: For link rel=icon we already define the /favicon.ico fallback. If a page lacks link rel=icon sizes we should probably also look at Apple's proprietary extension here given that it's quite widely adopted. Chrome supports it and there is some work going on in Firefox as well: https://bugzilla.mozilla.org/show_bug.cgi?id=921014 -- http://annevankesteren.nl/
Re: [whatwg] apple-touch-icon
On Sun, Jul 27, 2014 at 1:13 PM, Anne van Kesteren ann...@annevk.nl wrote: For link rel=icon we already define the /favicon.ico fallback. If a page lacks link rel=icon sizes we should probably also look at Apple's proprietary extension here given that it's quite widely adopted. Chrome supports it and there is some work going on in Firefox as well: https://bugzilla.mozilla.org/show_bug.cgi?id=921014 FWIW, Chrome’s intention was to drop support for Apple’s magic file names at some point. https://developer.chrome.com/multidevice/android/installtohomescreen#icon But I agree — it seems that this won’t happen any time soon. In case it helps, here’s some more info on touch icon support on various OS/devices: http://mathiasbynens.be/notes/touch-icons
Re: [whatwg] apple-touch-icon
Chrome 30 dropped support[1] for fetching apple-touch-icon-* from well known URLs, since the 404 pages that are usually returned were consuming 3-4% of all mobile bandwidth usage[2]. We're unlikely to reverse that. We still support apple-touch-icon-* via link rel under some circumstances (e.g. for add to homescreen), but they're deprecated[3], since we'd like authors to use the standard for this, i.e.: link rel=shortcut icon sizes=128x128 href=/favicon.png (or even good old: link rel=shortcut icon href=/favicon.ico with multiple resolutions in the .ico file for compatibility with IE11). [1]: https://code.google.com/p/chromium/issues/detail?id=259681 [2]: https://bugs.webkit.org/show_bug.cgi?id=104585 [3]: https://code.google.com/p/chromium/issues/detail?id=296962 On 28 July 2014 08:35, Mathias Bynens mathi...@opera.com wrote: On Sun, Jul 27, 2014 at 1:13 PM, Anne van Kesteren ann...@annevk.nl wrote: For link rel=icon we already define the /favicon.ico fallback. If a page lacks link rel=icon sizes we should probably also look at Apple's proprietary extension here given that it's quite widely adopted. Chrome supports it and there is some work going on in Firefox as well: https://bugzilla.mozilla.org/show_bug.cgi?id=921014 FWIW, Chrome’s intention was to drop support for Apple’s magic file names at some point. https://developer.chrome.com/multidevice/android/installtohomescreen#icon But I agree — it seems that this won’t happen any time soon. In case it helps, here’s some more info on touch icon support on various OS/devices: http://mathiasbynens.be/notes/touch-icons
Re: [whatwg] apple-touch-icon
Using a single JPEG/PNG that is also part of the home page display is a way to mitigate bandwidth used. Another way to do this is to use an SVG for a logo - which browsers support this now? On 28 Jul 2014 07:59, John Mellor joh...@google.com wrote: Chrome 30 dropped support[1] for fetching apple-touch-icon-* from well known URLs, since the 404 pages that are usually returned were consuming 3-4% of all mobile bandwidth usage[2]. We're unlikely to reverse that. We still support apple-touch-icon-* via link rel under some circumstances (e.g. for add to homescreen), but they're deprecated[3], since we'd like authors to use the standard for this, i.e.: link rel=shortcut icon sizes=128x128 href=/favicon.png (or even good old: link rel=shortcut icon href=/favicon.ico with multiple resolutions in the .ico file for compatibility with IE11). [1]: https://code.google.com/p/chromium/issues/detail?id=259681 [2]: https://bugs.webkit.org/show_bug.cgi?id=104585 [3]: https://code.google.com/p/chromium/issues/detail?id=296962 On 28 July 2014 08:35, Mathias Bynens mathi...@opera.com wrote: On Sun, Jul 27, 2014 at 1:13 PM, Anne van Kesteren ann...@annevk.nl wrote: For link rel=icon we already define the /favicon.ico fallback. If a page lacks link rel=icon sizes we should probably also look at Apple's proprietary extension here given that it's quite widely adopted. Chrome supports it and there is some work going on in Firefox as well: https://bugzilla.mozilla.org/show_bug.cgi?id=921014 FWIW, Chrome’s intention was to drop support for Apple’s magic file names at some point. https://developer.chrome.com/multidevice/android/installtohomescreen#icon But I agree — it seems that this won’t happen any time soon. In case it helps, here’s some more info on touch icon support on various OS/devices: http://mathiasbynens.be/notes/touch-icons
Re: [whatwg] apple-touch-icon
some data here: http://indiewebcamp.com/icon On Sun, Jul 27, 2014 at 5:13 AM, Anne van Kesteren ann...@annevk.nl wrote: For link rel=icon we already define the /favicon.ico fallback. If a page lacks link rel=icon sizes we should probably also look at Apple's proprietary extension here given that it's quite widely adopted. Chrome supports it and there is some work going on in Firefox as well: https://bugzilla.mozilla.org/show_bug.cgi?id=921014 -- http://annevankesteren.nl/
