On Mon, Jul 28, 2014 at 8:34 PM, Ian Hickson i...@hixie.ch wrote:
What's the use case here? Why are we trying to send custom headers on a
link?
E.g. for img and such you want to turn authentication dialogs off.
Cross-origin images can be fine, but not if they start spawning
confusing dialogs to
On Mon, Jul 28, 2014 at 8:16 PM, Adam Barth w...@adambarth.com wrote:
I meant a black-box experiment (i.e., no access to browser internal state).
Put another way, can you describe a sequence of events in which the author
or the user could observe the difference? If not, then the question is
Either:
1) The frames attempt no synchronization and both just call
requestFullscreen(). In that case, the observable difference is largely
moot. It shouldn't be surprising that racing operations like this cross
origin returns a non-deterministic result. This is the position the Chrome
On Thu, Jul 17, 2014 at 2:26 PM, duanyao duan...@ustc.edu wrote:
I think rule 5.1 should be applied to both static fetching and XHR
consistently. Browsers should set Content-Type header to local files' actual
type for XHR, and interpret
them accordingly. But firefox developers think this
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
On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng dch...@google.com wrote:
1) The frames attempt no synchronization and both just call
requestFullscreen(). In that case, the observable difference is largely
moot. It shouldn't be surprising that racing operations like this cross
origin returns a
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
于 2014/7/29 18:48, Anne van Kesteren 写道:
On Thu, Jul 17, 2014 at 2:26 PM, duanyao duan...@ustc.edu wrote:
I think rule 5.1 should be applied to both static fetching and XHR
consistently. Browsers should set Content-Type header to local files' actual
type for XHR, and interpret
them
To summarize a discussion we had about this on IRC today:
http://krijnhoetmer.nl/irc-logs/whatwg/20140729#l-509
Jungkee wrote a helpful document for features using Service Workers as well:
https://gist.github.com/jungkees/3154398b8deee7c70139
The |serviceWorker| attribute can be added
Another concrete example with img tags: sometimes an abusive user will
use a site like Facebook as a CDN -- they'll upload a picture and hotlink
it from elsewhere. We could insert a time-stamped authentication token as a
custom header. Today we sometimes do this via the query string -- giving
the
On Tue, Jul 29, 2014 at 5:14 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng dch...@google.com wrote:
1) The frames attempt no synchronization and both just call
requestFullscreen(). In that case, the observable difference is largely
moot. It
On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote:
Given that you haven't produced a black-box experiment that
distinguishes the two approaches, different implementations can use
different approaches and be interoperable.
I guess. That still doesn't help us much defining it.
On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote:
Given that you haven't produced a black-box experiment that
distinguishes the two approaches, different implementations can use
different approaches
On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote:
Given that you haven't produced a black-box experiment that
distinguishes the two approaches, different implementations can use
different
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
15 matches
Mail list logo
