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] Proposal: navigator.launchURL
Hi! On 7/16/14, 1:24 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 15, 2014 at 12:28 AM, Ian Hickson i...@hixie.ch wrote: Introducing a new API that literally doesn't do anything you can't already do is a pretty high cost, IMHO. It seems there are some potential differences: Ian and Adam, what do you think about the points raised by Anne and me? For the window.open approach that you proposed, how would the API look like? What would the API return if an external app was launched? Cheers, Kosta -- Cheers, Konstantin Welke Senior Software Developer Citrix Online Germany GmbH | Erzbergerstr. 117 | D-76133 Karlsruhe http://www.citrixonline.com http://www.citrixonline.com/ Work better. Live better. Citrix Online Germany GmbH | Erzbergerstr. 117 | D-76133 Karlsruhe Geschäftsführer: Tommy Ahlers | David Zalewski | Michael DiFilippo Sitz der Gesellschaft: Karlsruhe | Registergericht: Amtsgericht Mannheim HRB 713721 Citrix Online UK Ltd http://www.citrixonline.com/imprint-en.tmpl
[whatwg] Accept header
The way service workers work is that only headers set at the API-level will be exposed to service workers. E.g. Host is not exposed as the network-level takes care of that (and you can simply use request.url for it). Per https://github.com/slightlyoff/ServiceWorker/issues/303 https://github.com/slightlyoff/ServiceWorker/issues/348 it would be desirable to have Accept / Accept-Language be set by APIs, such as img. XMLHttpRequest already does this (unless a developer added those headers), see http://xhr.spec.whatwg.org/ Any idea how to best define this Ian? If we are eventually going to expose something like a Fetch object for each API that can issue a fetch it would seem best if these details were defined at the API-level. I guess for now I'll add some notes to the network-level bits of Fetch to indicate Accept / Accept-Language cannot be set at that point by the user agent. -- http://annevankesteren.nl/
Re: [whatwg] How to determine content-type of file: protocol
On Tue, Jul 29, 2014 at 4:26 PM, 段垚 duan...@ustc.edu wrote: 于 2014/7/29 18:48, Anne van Kesteren 写道: There's an enormous amount of tricky things to define around file URLs, this being one of them. Are there some resources on those tricky things? No, not really. But it's a short list: 1) Parsing 2) Mapping a parsed file URL to an OS-specific filesystem (case-sensitivity, case folding, ...) 3) Turning the resource into something that looks like a HTTP response 1 is for the URL Standard and would ideally be agnostic of OS. 2 and 3 would be for the Fetch Standard, if we were to define the details. I'm hoping to get 1 done at least. I agree that file protocol is less important than http. However packaged web applications (PhoneGap app, Chrome app, Firefox OS app, Window 8 HTML app, etc) are increasing their popularity, and they are using file: protocol or similar things to access their local assets. So I think it's worthwhile to work on file protocol to reduce porting issues of packaged web applications. Well, or similar is important. Because those things are not really similar at all but instead something that's actually portable across systems and something we can reasonably standardize. Firefox developers said they won't change their implementation of XHR with file: before the spec explicitly define the behavior, so it looks like a chicken-egg problem to me. I guess. Also I'd like to know some general principles of introducing new URL schemes (like file:) into web standards: (1) Should new URLs mimic http's behaviors as much as possible? Such as status codes, content-type, etc. (2) Should XHR and static resource fetching behave consistently with new URLs? As a web developer, my personal answers are all yes. Sure. -- http://annevankesteren.nl/
Re: [whatwg] Accept header
On Wed, 30 Jul 2014, Anne van Kesteren wrote:
it would be desirable to have Accept / Accept-Language be set by APIs,
such as img. XMLHttpRequest already does this (unless a developer
added those headers), see http://xhr.spec.whatwg.org/
If we are eventually going to expose something like a Fetch object for
each API that can issue a fetch it would seem best if these details were
defined at the API-level.
I guess for now I'll add some notes to the network-level bits of Fetch
to indicate Accept / Accept-Language cannot be set at that point by the
user agent.
There's three ways that I see:
1. Expose it on a fetch object available from all the places that can
do fetches. (HTMLImageElement, XMLHttpRequest, StyleSheet, etc)
var img = new Image();
img.src = 'foo.png';
img.fetch.doWhateverWithTheAcceptHeader('foo');
2. Expose a dedicated attribute on relevant elements, that sets the
default fetch settings, either using some generic syntax:
img src=foo.png fetchoptions={whatever:{accept:'foo'}}
...or some nicer dedicated syntax:
img src=foo.png fetchoptions=accept: foo; whatever: bar
3. Have multiple dedicated attributes:
img src=foo.png accept=foo whatever=bar
These are not mutually exclusive.
I would avoid adding the non-API sugar versions (content attributes,
especially the dedicated ones) for anything that didn't have significant
compelling use cases.
Note that Accept _should_ probably be set by the UA for images, since
the author can't know what image types are supported.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Accept header
On Wed, Jul 30, 2014 at 8:35 PM, Ian Hickson i...@hixie.ch wrote: I would avoid adding the non-API sugar versions (content attributes, especially the dedicated ones) for anything that didn't have significant compelling use cases. Agreed. Note that Accept _should_ probably be set by the UA for images, since the author can't know what image types are supported. This was actually my main point phrased somewhat awkwardly I realize now. Specifications that define APIs that use Fetch need to invoke the fetch algorithm and say whether Accept / Accept-Language should be included. Perhaps even recommend values as XMLHttpRequest does. That means Fetch will expose those headers to service workers. That means if we add a Fetch object of sorts they can be manipulated. That also means Fetch will forbid UAs from setting them at the network-level, giving e.g. fetch() full control over them. -- http://annevankesteren.nl/
