[whatwg] No interface flicker across page loads, without JavaScript (was: framesets)

[Aryeh Gregor]

On Fri, Oct 16, 2009 at 7:16 AM, Markus Ernst <derernst at gmx.ch> wrote:
> Interesting idea! Anyway it introduces some consistency problems to solve,
> e.g.:
>
> Page1.html contains:
>
> <static id="foo">I eat meat</static>
>
> and links to page2.html, which contains:
>
> <static id="foo">I am a vegetarian</static>
>
> So page2.html looks different whether it is called from the link in
> page1.html, or directly via a bookmark, external link, or manual URI input.

Well, certainly impose a same-origin restriction on preservation of
<static>.  Then it would just be a problem of one site being
inconsistent with itself.  But I don't think this is a bug, it's a
feature.  One of the major advantages of frames is you can manipulate
each piece independently, and not have your changes lost on
navigation.  If a script changes the contents of the <static> after it
was created, those changes *should* be required to persist on page
load.

An alternative idea would be to dispense with id's, and key off a hash
of the literal string contents of the <static> instead, in the
serialized document passed over the wire.  Bandwidth savings could
then be obtained using <static hash="..."></static> or some similar
syntax, with the UA passing the hashes instead of id's in a header.
This way, the element would auto-update if the contents changed on the
server side, but not on the client side.

On the other hand, if they did change it would lose all the user's
changes, if any.  But you can't rely on the changes being present
after page reload anyway, if the element has been changed, so maybe
this is noncritical.  It depends what exactly this would be used for.

The obvious use case here would just be to keep navigation elements
fixed.  For instance, on http://en.wikipedia.org/wiki/, most of <div
id=column-one> could be <static>.  (With a few exceptions, like <div
id="p-cactions">.)  Navigation tends not to be very interact-able, so
reloading it and throwing out client-side changes would be fine if it
changes on the server side.

A slightly different use-case would be a dynamic application like
Gmail, rewritten without AJAX.  The bar on the left contains things
like "Inbox (2)", which are updated by script.  In this case, if new
contents were loaded from the server, the server or script would
promptly fill in the appropriate numbers and so on.  So again, this
use-case doesn't seem to care much if changes are thrown out.

Another case to consider is where you have a tree or something that
gets uncollapsed depending on what page you're on.  This seems like a
case where you'd actually want something slightly different: the new
version should load, just without flickering.  Perhaps a cruder
solution would be useful, which doesn't affect display of the new page
but only how new elements get loaded -- specifically, allowing a mix
of content from the old and new page to exist until the new page is
fully painted.  I'm not sure how that would work.  The sort of
compression I suggested in <static> could probably be better handled
by SDCH or something.

> This could be solved if "static" elements have no content on their own, but
> retrieve it from an external source. The identifyer is then not the id
> attribute, but the source. This could be done with a src attribute on the
> <static> element. But I assume an easier implementation would be adding a
> "static" attribute for the <iframe> element, indicating that the iframe
> contents should not be reloaded.

I don't like this solution, because it complicates things for authors.
 You have to make separate pages for each interface widget, and it
entails more HTTP requests.  It's also not backwards-compatible --
you'll often get a big degradation in behavior if you use this in a
browser that doesn't support <iframe seamless>.  <static> as I
envisioned it can be dropped into existing pages without requiring
them to be broken into separate files, or risking compatibility
problems.