On 2014-08-14, 4:53 PM, John Schoenick wrote:
On 08/14/2014 12:50 PM, Jonas Sicking wrote:
On Thu, Aug 14, 2014 at 12:37 PM, John Schoenick
wrote:
On 08/14/2014 11:48 AM, Jonas Sicking wrote:
On Thu, Aug 14, 2014 at 10:28 AM, Gavin Sharp
wrote:
On Thu, Aug 14, 2014 at 8:32 AM, Ehsan Akhgari
On 08/14/2014 12:50 PM, Jonas Sicking wrote:
On Thu, Aug 14, 2014 at 12:37 PM, John Schoenick wrote:
On 08/14/2014 11:48 AM, Jonas Sicking wrote:
On Thu, Aug 14, 2014 at 10:28 AM, Gavin Sharp
wrote:
On Thu, Aug 14, 2014 at 8:32 AM, Ehsan Akhgari
wrote:
In this context, an app that performs
On Thu, Aug 14, 2014 at 12:37 PM, John Schoenick wrote:
> On 08/14/2014 11:48 AM, Jonas Sicking wrote:
>>
>> On Thu, Aug 14, 2014 at 10:28 AM, Gavin Sharp
>> wrote:
>>>
>>> On Thu, Aug 14, 2014 at 8:32 AM, Ehsan Akhgari
>>> wrote:
>
> In this context, an app that performs in-place update
On 08/14/2014 11:48 AM, Jonas Sicking wrote:
On Thu, Aug 14, 2014 at 10:28 AM, Gavin Sharp wrote:
On Thu, Aug 14, 2014 at 8:32 AM, Ehsan Akhgari wrote:
In this context, an app that performs in-place updates, as opposed to full
page reloads, when transitioning between different views. The view
On Thu, Aug 14, 2014 at 10:28 AM, Gavin Sharp wrote:
> On Thu, Aug 14, 2014 at 8:32 AM, Ehsan Akhgari
> wrote:
>>> In this context, an app that performs in-place updates, as opposed to full
>>> page reloads, when transitioning between different views. The views can
>>> use
>>> different JS, CSS,
On Thu, Aug 14, 2014 at 8:32 AM, Ehsan Akhgari wrote:
>> In this context, an app that performs in-place updates, as opposed to full
>> page reloads, when transitioning between different views. The views can
>> use
>> different JS, CSS, and so on. To achieve this, you have to build your app
>> in a
On 2014-08-14, 1:44 AM, Ilya Grigorik wrote:
On Wed, Aug 13, 2014 at 5:16 PM, Jonas Sicking wrote:
On Wed, Aug 13, 2014 at 12:24 PM, Ilya Grigorik
wrote:
On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking wrote:
Do you really think that Google would be able to morph a google
calendar page
On Wed, Aug 13, 2014 at 5:16 PM, Jonas Sicking wrote:
> On Wed, Aug 13, 2014 at 12:24 PM, Ilya Grigorik
> wrote:
> > On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking wrote:
>
> Do you really think that Google would be able to morph a google
> calendar page into the google search result page?
>
On Wed, Aug 13, 2014 at 12:24 PM, Ilya Grigorik wrote:
> On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking wrote:
>>
>> On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik
>> wrote:
>> > Whereas for (b) you can also do it in place by prefetching the template
>> > and then issuing a data request for rele
On 2014-08-13, 3:24 PM, Ilya Grigorik wrote:
On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking wrote:
On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik
wrote:
Whereas for (b) you can also do it in place by prefetching the template
and then issuing a data request for relevant data once you know th
On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking wrote:
> On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik
> wrote:
> > Whereas for (b) you can also do it in place by prefetching the template
> and then issuing a data request for relevant data once you know the exact
> URL... Which, of course, is ex
(reposting, got stuck in the queue)
On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking wrote:
> On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik
> wrote:
> > Whereas for (b) you can also do it in place by prefetching the template
> and then issuing a data request for relevant data once you know the e
On Tue, Aug 12, 2014 at 6:53 PM, Karl Dubost wrote:
> Le 13 août 2014 à 10:09, Jonas Sicking a écrit :
>>> And what would be the fallback for non JS user agents (cue accessibility
>>> and HTTP scripting here)?
>>
>> The same as any other time when prerendering is used. The fallback
>> would simp
Just to be clear I have *read*
http://code.google.com/chrome/whitepapers/prerender.html
So my understanding of pretender is based on this whitepaper. :)
Le 13 août 2014 à 10:09, Jonas Sicking a écrit :
>> And what would be the fallback for non JS user agents (cue accessibility and
>> HTTP script
On Tue, Aug 12, 2014 at 5:47 PM, Karl Dubost wrote:
>
> Le 13 août 2014 à 09:13, Jonas Sicking a écrit :
>> The goal of prerender is to improve performance when navigating to a
>> new page.
>
> my understanding too.
>
>> I'm talking about doing a full rendering of a "template page". I.e. a
>> nor
On 08/12/2014 04:04 PM, Ilya Grigorik wrote:
In short, seems like this is inventing a derivative single-page app model for
building pages/apps, and that makes me wonder because it doesn't seem to make
it any easier. Everything described here can be achieved with current tools,
but perhaps coul
Le 13 août 2014 à 09:13, Jonas Sicking a écrit :
> The goal of prerender is to improve performance when navigating to a
> new page.
my understanding too.
> I'm talking about doing a full rendering of a "template page". I.e. a
> normal webpage which the website can then use JavaScript to mutate
On Tue, Aug 12, 2014 at 4:18 PM, Karl Dubost wrote:
> Jonas,
> thanks for the explanations so far. It helps a lot to understand and sorry
> for the naive questions. There is still something I do not get:
>
> Le 13 août 2014 à 07:17, Jonas Sicking a écrit :
>> It would be much more practically do
Jonas,
thanks for the explanations so far. It helps a lot to understand and sorry for
the naive questions. There is still something I do not get:
Le 13 août 2014 à 07:17, Jonas Sicking a écrit :
> It would be much more practically doable for calendar instead to
> prerender a blank search result
On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik wrote:
>
> I'm still trying to wrap my head around the use case, but I'm with you on
> this so far...
[snip]
> It seems like there are two cases to consider here:
> (a) You're on a page with the same base template as destination
> (b) You're navigati
An alternative solution to templates for this use case is the following:
1) In the prerendered page's html, group preloaded resources (LINK
rel=subresource currently) into "base" and "extended" hints. This can be
accomplished by a new LINK attribute, for example.
2) The prerenderer can then fetc
On Tuesday, August 12, 2014 8:39:11 AM UTC-7, Jesper Kristensen wrote:
> This templated prerendereing sounds like a complicated API. Is there any
> advantage of this over what is possible today with a single page
> application using history.pushState?
I'm still trying to wrap my head around the
On 2014-08-12, 11:39 AM, Jesper Kristensen wrote:
This templated prerendereing sounds like a complicated API. Is there any
advantage of this over what is possible today with a single page
application using history.pushState?
Yes, I think so. The idea of single page applications is nice, but it
This templated prerendereing sounds like a complicated API. Is there any
advantage of this over what is possible today with a single page
application using history.pushState?
Den 12-08-2014 kl. 00:03 skrev Jonas Sicking:
Very exited to see this happening.
Implementation issues aside, I have t
On 2014-08-11, 6:03 PM, Jonas Sicking wrote:
Very exited to see this happening.
Implementation issues aside, I have two comments:
* This is something that we really need on FirefoxOS. I hope that the
implementation strategy will work there too?
Yes, the majority of the code is going to be sha
On Mon, Aug 11, 2014 at 5:16 PM, Karl Dubost wrote:
> Jonas,
>
> Le 12 août 2014 à 08:33, Jonas Sicking a écrit :
>> However in some cases we can do better than that by loading a template
>> page that can be used for multiple of the search results.
>
> This I'm not sure to understand how that wou
Jonas,
Le 12 août 2014 à 08:33, Jonas Sicking a écrit :
> However in some cases we can do better than that by loading a template
> page that can be used for multiple of the search results.
This I'm not sure to understand how that would be working. Let's say be any
page on the Web. How do you kn
On Mon, Aug 11, 2014 at 3:40 PM, Karl Dubost wrote:
>
> Le 12 août 2014 à 07:03, Jonas Sicking a écrit :
>> * A use-case that we came upon pretty quickly when we were looking at
>> using prerendering in FirefoxOS is that we might not know the exact
>> URL that the user is likely to navigate to, b
an obvious tie in here is the network predictor (formerly 'seer') work Nick
Hurley has been doing. Basically already working on the "what to fetch
next" questions, but not the rendering parts.
On Mon, Aug 11, 2014 at 6:40 PM, Karl Dubost wrote:
>
> Le 12 août 2014 à 07:03, Jonas Sicking a écri
Le 12 août 2014 à 07:03, Jonas Sicking a écrit :
> * A use-case that we came upon pretty quickly when we were looking at
> using prerendering in FirefoxOS is that we might not know the exact
> URL that the user is likely to navigate to, but we have a pretty good
> guess about what template page i
Very exited to see this happening.
Implementation issues aside, I have two comments:
* This is something that we really need on FirefoxOS. I hope that the
implementation strategy will work there too?
* A use-case that we came upon pretty quickly when we were looking at
using prerendering in Firef
Summary: The Prerendering API allows the rendering engine to start loading and
rendering a web page without any visible UI until the page needs to be
displayed to the user. It's a gecko API that consumers can choose to use. For
now, we're not talking about exposing this to web pages yet, or even
32 matches
Mail list logo
