On 2014-08-13, 3:24 PM, Ilya Grigorik wrote:
On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking <jo...@sicking.cc> wrote:
On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik <igrigo...@gmail.com>
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 exactly how single-page apps work today.
I don't understand what you are saying here.
The point of (b) is that the different base templates. So it'd be very
hard to use pushState and DOM mutations to morph the current page into
the destination page. The fact that the destination page is template
based doesn't make it any easier.
It's been done before, and with pretty good success:
- http://pjax.heroku.com/
- https://github.com/rails/turbolinks - derivative of pjax and in fairly
wide use, since its core to Rails.
As turbolinks repo notes, you get the most benefit from this technique when
you preserve the same CSS/JS... but the point is, full replace is not out
of scope either.
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.
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.
Well, firstly, this doesn't _need_ to be same origin as the controlling
document. Think of wikipedia where their application is spread across
tons of origins.
Also, with your proposal, how would the prerendered page know about the
actual URL? (We could borrow the bit from my proposal about extending
the event object.)
But most importantly, we need to think about the case where the
prerendered template page can't actually handle the URL that the
controlling document claims in their <link rel=prerender>. How would
the page signal this to the browser so that we know to throw away the
prerendered content and do a normal navigation?
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
