On 2014-08-14, 1:44 AM, Ilya Grigorik wrote:
> On Wed, Aug 13, 2014 at 5:16 PM, Jonas Sicking <
jo...@sicking.cc> wrote:
>
>> On Wed, Aug 13, 2014 at 12:24 PM, Ilya Grigorik <
igri...@gmail.com>
>> wrote:
>>> On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking <
jo...@sicking.cc> wrote:
>>
>
>> Do you really think that Google would be able to morph a google
>> calendar page into the google search result page?
>>
>
> <aside>
> While this is mostly orthogonal to our discussion, worth checking out if
> you're not familiar with it:
>
https://groups.google.com/a/chromium.org/d/msg/blink-dev/lWCtrTynaVk/Bvf4jIeEuPcJ
>
> Obviously, the above does not make the page transition faster, but it does
> provide a "morph facility".
> </aside>
I don't understand how this is related to the current discussion. The
proposal there seems to be about some kind of IE4 style transition as
the navigation is happening
(
http://msdn.microsoft.com/en-us/library/ms532847%28v=vs.85%29.aspx). I
don't think that is related to prerendering...
>>> On Tue, Aug 12, 2014 at 7:19 PM, Jonas Sicking <
jo...@sicking.cc> wrote:
>>>>
>>>> On Tue, Aug 12, 2014 at 6:53 PM, Karl Dubost <
kdu...@mozilla.com>
>> wrote:
>>>>> Le 13 août 2014 à 10:09, Jonas Sicking <
jo...@sicking.cc> a écrit :
>>>> But yes, this depends on scripting. It sounds like between the two of
>>>> us we have three goals
>>>>
>>>> * Enable fast navigation between webpages in websites like bugzilla.
>>>> * When a search result page is loaded, avoid loading and prerendering
>>>> a separate DOM for each bug.
>>>> * Avoid relying on JS.
>>>
>>>
>>> So, same origin; substantially different page template; single-page app.
>>
>> I'm not sure why you say "single-page app"? The bugzilla search result
>> page and the page rendering individual bugs are decidedly different
>> pages right now. I.e. the DOM looks very different, they run different
>> scripts, they are generated from different server-side scripts and
>> they use different URLs, including the parts before the #.
>>
>> Maybe I don't understand what your definition of "single-page app" is.
>>
>
> 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 very particular way. In the case of bugzilla, that would involve a
> substantial rewrite of the app... you can't just drop in a few prerender
> tags on the page and defer the rest to the browser.
The point of what Jonas and I are talking about is to avoid having to
rewrite the app. The existing URLs and pages will be preserved for
normal (non-prerendered) navigation, and the app would need to implement
a separate template page which knows how to load the barebone
CSS/JS/images and then fill in the rest based on the information
received from the controlling document.
>>> It seems like the workflow you're after is something like:
>>> <link rel="prerender" href="/some/other/template.html"
>>> route="/other-thing/*" id="ABC">
>>>
>>> When a navigation is initiated to "/other-thing/random", the above
>> prerender
>>> context is used:
>>> - prerender context gets a notification that its visible (i.e. Page
>>> Visibility API)
>>> - prerender context inspects the actual target URL, extract right tokens
>>> from it, does its thing...
>>>
>>> Is there even a need for postMessage, etc? Seems like the necessary
>> pieces
>>> are already there - i.e. the URL.
>>
>> The point of the postMessage was mainly to expose the actual target
>> URL. I.e. by enabling a message channel between the initiating page
>> and the prerendered page we wouldn't need to invent an API for
>> exposing the target URL. Nor would we need to add a route attribute or
>> define a URL pattern matching syntax.
>>
>
> Why can't I just listen for visibilitychange event and then query
> document.location in the handler?
Because your document.location will reflect the URL of the loaded page,
not the URL of the navigation target. The issue is that the controlling
page will have several links such as
http://app.com/result1,
http://app.com/result2,
http://app.com/someotherresult etc. Before the
user decides which one they want to click on, neither the browser nor
the app know which URL to prerender.
> I'm intentionally handwaving my way
> through the implementation details, but roughly, I'm picturing it as:
> render this template, it'll match any of these routes; navigation is
> invoked; matching prerender is found and is used to render the remainder of
> the page content.
Like I asked before, what if the prerendered template page is unable to
handle the actual navigation target? In the example above, let's
imagine that result2 cannot be handled by the prerendered page for some
reason. It seems like with your proposal, the template page has no way
of indicating this to the browser, so if the user clicks on result2 then
the browser will render the prerendered template page which probably has
the wrong content on it.
>> (Note: I'm still a bit skeptical of the use case, but... curious :))
>>
>> The use case here is any search interface, as well as any page that
>> contains links to database generated content. Both are incredibly
>> common on the web. And, like Eshan points out, it works even when
>> those navigate across origins.
>>
>
> ... assuming all of those pages are rewritten to take advantage of this
> technique, which is no small ask.
There will be no massive rewrite.
> To make matters worse, at least as
> implemented today, prerender is a speculative thing that may or may not
> happen. In which case, all of the sites would also have to implement a
> fallback.
Well this is opt-in. If the controlling document wants to prerender a
template page like this without the target web site supporting that,
then we'll fall back to normal navigation.
>> So for example:
>> * Amazon's product search UI
>> * Amazon's search result UI
>> * Wikipedia's search UI
>> * Wikipedia's search result UI
>> * The search UI on NY Times
>> * The search results UI on NY Times
>> * Almost any product listing page
>> * A contacts manager which uses "real" URLs rather than fragment-based
>> URLs.
>>
>
>> I'm not sure why you are skeptical about that use case?
>>
>
> All of these are plausible today with current infrastructure. I'm not
> skeptical of the examples, I'm skeptical of the value add of this API on
> top of what's out there today.
The interesting thing about these use cases is that on each one of these
pages there is a number of different links that the user can click on,
and without knowing which one will be clicked beforehand, the website
can't prerender anything useful. The best it would be able to do with
the current API is to prerender the first result or some such.
>> And to be clear, I'm not proposing making major changes or additions
>> to the current spec. The only suggested changes is to add support for
>> having a message channel, and that if the prerendered page calls
>> replaceState that we match against the new URL rather than the URL
>> that was originally loaded.
>>
>
> You'd also need the ability to tell the UA to match against some URL
> pattern, which we don't have today. Right?
No, the matching would be exact. With the example above, let's say that
we have prerendered
app.com/template. In the onclick handler for
result1, we'd send a message to the target page signaling it that
result1 has been picked, and the template page will replaceState its URL
to be
app.com/result1, at which point the browser will do an exact match
between the prerendered doucument's URI and the navigation target, and
because they both match, the prerendered document will be rendered. If
result2 is clicked however, the onmessage handler in the template page
decides that it is unable to handle that, and doesn't replaceState, so
the browser will fail to match the URL to be loaded with any prerendered
content, so it will fall back to normal navigation.
Cheers,
Ehsan