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