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 fo
On Wed, Jul 30, 2014 at 10:48 AM, Niels Keurentjes
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/
- Original Message -
> From: "Niels Keurentjes"
> Cc: "WHATWG"
> 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 /fa
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
On Wed, Jul 30, 2014 at 11:02 AM, Niels Keurentjes
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
inte
Hi!
On 7/16/14, 1:24 PM, "Anne van Kesteren" wrote:
>On Tue, Jul 15, 2014 at 12:28 AM, Ian Hickson 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 thi
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.c
On Tue, Jul 29, 2014 at 4:26 PM, 段垚 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)
On Wed, 30 Jul 2014, Anne van Kesteren wrote:
>
> it would be desirable to have Accept / Accept-Language be set by APIs,
> such as . XMLHttpRequest already does this (unless a developer
> added those headers), see http://xhr.spec.whatwg.org/
>
> If we are eventually going to expose something li
On Wed, Jul 30, 2014 at 11:35 AM, Ian Hickson wrote:
> On Wed, 30 Jul 2014, Anne van Kesteren wrote:
> >
> > it would be desirable to have Accept / Accept-Language be set by APIs,
> > such as . XMLHttpRequest already does this (unless a developer
> > added those headers), see http://xhr.spec.what
On Wed, Jul 30, 2014 at 8:35 PM, Ian Hickson 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 image
11 matches
Mail list logo
