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 to warm things up if possible and viola things are more responsive if those hints are taken. On Tue, Oct 30, 2012 at 2:58 PM, Mounir Lamouri wrote: > 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% in our testing. We are using it on > > sites - mail.yandex.ru/prefetch.txt has an example). > > > > The draft "spec" here is still very rough, but it shows what we've > > implemented and some of what we think it is good for. > > > > This is meant as input to the appcache/packaging/etc discussion, and may > > or may not be something this group takes on. > > At a first glance, it seems that appcache could do the same things. > Which use cases appcache can't currently solve? In the process of fixing > appcache, it could be interesting to add those use cases. > > -- > Mounir > >
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% in our testing. We are using it on > sites - mail.yandex.ru/prefetch.txt has an example). > > The draft "spec" here is still very rough, but it shows what we've > implemented and some of what we think it is good for. > > This is meant as input to the appcache/packaging/etc discussion, and may > or may not be something this group takes on. At a first glance, it seems that appcache could do the same things. Which use cases appcache can't currently solve? In the process of fixing appcache, it could be interesting to add those use cases. -- Mounir
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 Web platform. > > Here are some possibilities, not necessarily mutually exclusive: > > (1) > > Specify templates via external files rather than inline content. External > CSS and external scripts are very common, and in most cases inline scripts > and style are the exception. It seems likely this will also be true for > templates. It's likely desirable to provide this even if there is also some > inline form of templates. > > (2) > > Use the same approach as to specifying content inline > while remaining compatible with legacy parsing. The main downside is that > the required escaping is ugly and hard to follow, especially in the face of > nesting. > > (3) (or