Re: Pre-fetch rough draft

The appcache is encumbered with guarantees about atomically updating a set of resources and then explicitly not hitting the network for them once up to date to ensure the site/app will function if the network really is complete gone. This gist of this prefetch list seems different. More of a hint

Re: Pre-fetch rough draft

On 10/30/2012 10:22 AM, Charles McCathieNevile wrote: > Hi, > > I mentioned this and it's somethign we are working on. > > Basic idea: site provides list of resources that it uses and can be > cached for general improvements on the whole site. (We're seeing > load-time improvement from 50% - 300%

Re: [webcomponents] More backward-compatible templates

On Tue, Oct 30, 2012 at 6:58 AM, Maciej Stachowiak wrote: > > In the WebApps meeting, we discussed possible approaches to > that may ease the transition between polyfilled implementations and native > support, avoid HTML/XHTML parsing inconsistency, and in general adding less > weirdness to the

Draft Minutes: 30 October 2012

The Draft minutes from WebApps' October 30 f2f meeting are in and are copied below. If you have any corrections, please send them to this list by November 6. -Thanks, AB W3C - DRAFT - WebApps F2F Meeting 30 Oct

[Clipboard API] The before* events

I'm looking at the beforecut, beforecopy and beforepaste events. I don't entirely understand their intent, it seems even more obscure than I expected.. Nothing in the official MSDN documentation [1] really explains the interaction between beforecopy and copy (given that you can control th

[webcomponents] More backward-compatible templates

In the WebApps meeting, we discussed possible approaches to that may ease the transition between polyfilled implementations and native support, avoid HTML/XHTML parsing inconsistency, and in general adding less weirdness to the Web platform. Here are some possibilities, not necessarily mutual

Re: Pre-fetch rough draft

On 2012-10-30 11:44, Yuval Sadan wrote: Adding another "well-known location" may cause (yet another) 404 error for sites lacking this file, similar to favicon.ico. Plus it takes up URL space. I suggest that if such a file is used, it should not be in a "well-known location" but a site specific lo

Re: Pre-fetch rough draft

On 2012-10-30 11:31, Brady Eidson wrote: On Oct 30, 2012, at 11:19 AM, Julian Reschke wrote: On 2012-10-30 10:57, Anne van Kesteren wrote: On Tue, Oct 30, 2012 at 10:46 AM, Florian Bösch wrote: The specification states that "Prefetch requests must not include cookies." which is not an effe

Re: [quota-api] Need for session storage type

Reviving this thread as well... to give a chance to get more feedbacks before moving this forward. Let me briefly summarize: The proposal was to add 'Session' storage type to the quota API, whose data should get wiped when the session is closed. Past related discussion: * Should the data go away

Re: Pre-fetch rough draft

Adding another "well-known location" may cause (yet another) 404 error for sites lacking this file, similar to favicon.ico. Plus it takes up URL space. I suggest that if such a file is used, it should not be in a "well-known location" but a site specific location that can be specified by an HTTP he

Re: [quota-api] API change suggestions

(Reviving this old thread as I'd like to make this API stable and would like to see more feedbacks...) Let me briefly summarize the proposed API change and its pros/cons: * The existing API [getUsageAndQuota(), returns two long long integers] is horrible but (hopefully) comprehensible. As a Chro

[Bug 19773] New: Add sandboxed pointer lock flag to HTML Sandboxing

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19773 Priority: P3 Bug ID: 19773 CC: i...@hixie.ch, m...@w3.org, public-html-wg-issue-track...@w3.org, public-h...@w3.org, public-webapps@w3.org, sch...@

Re: Pre-fetch rough draft

On 2012-10-30 10:57, Anne van Kesteren wrote: On Tue, Oct 30, 2012 at 10:46 AM, Florian Bösch wrote: The specification states that "Prefetch requests must not include cookies." which is not an effective measure to prevent user profiling. I suspect it's to reduce the size of the request. ->

Re: Pre-fetch rough draft

It's also a little unclear to me how prefetch improves the html manifest or how they compare. It seems as if prefetch does pretty much the same as the manifest except that it distributes fetching of the actual resources out over time that the user might not be visiting a site. Wouldn't it make more

Re: Pre-fetch rough draft

On 2012-10-30 10:22, Charles McCathieNevile wrote: Hi, I mentioned this and it's somethign we are working on. Basic idea: site provides list of resources that it uses and can be cached for general improvements on the whole site. (We're seeing load-time improvement from 50% - 300% in our testing

Re: Pre-fetch rough draft

On Tue, Oct 30, 2012 at 10:46 AM, Florian Bösch wrote: > The specification states that "Prefetch requests must not include > cookies." which is not an effective measure to prevent user profiling. I suspect it's to reduce the size of the request. -- http://annevankesteren.nl/

Re: Pre-fetch rough draft

The specification states that "Prefetch requests must not include cookies." which is not an effective measure to prevent user profiling. For instance somebody could auto generate the prefetch.txt tailored to the user to fetch URLs like to http://somedomain.com/whatever?userID=1358f2d55b34fb581fd547

Pre-fetch rough draft

Hi, I mentioned this and it's somethign we are working on. Basic idea: site provides list of resources that it uses and can be cached for general improvements on the whole site. (We're seeing load-time improvement from 50% - 300% in our testing. We are using it on sites - mail.yandex.ru/pr