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 <igrigo...@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 <kdub...@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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
