W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

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

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Fri, 16 Oct 2009 06:33:52 -0400
Message-ID: <7c2a12e20910160333n70195296i5abaf9fad72a27b1@mail.gmail.com>
On Thu, Oct 15, 2009 at 3:49 AM, Nelson Menezes
<flying.mushroom at gmail.com> wrote:
> As an aside, there is a reason why AJAX has become so popular over the
> past few years: it solves the specific UI-reset issue that is inherent
> in full-page refreshes.

I'm trying to think what a solution to this would look like.  Maybe
something like:

<static id=foo>Some stuff that doesn't change on page load...</static>
Changeable page content
<static id=bar>Some more stuff that doesn't change...</static>

The semantics would be that when the browser loaded the new page, it
would do something like

1) Retrieve the URL.
2) Start parsing the new page.  When the time comes to clear the
screen so it can be redrawn for the new page, leave any <static>
elements untouched, so they don't flicker or vanish.
3) When parsing the page, if a <static> element is reached that has
the same id as a <static> element that was on the old page, ignore the
contents of the new one.  Instead, move the old <static> element to
the position of the new one, copying its DOM.  If possible, this
shouldn't cause the visible <static> element to flicker or be redrawn,
if it's visible.  There should be some reasonable de facto or de jure
conditions where no-flicker is guaranteed, e.g., all applicable styles
are the same and the element is absolutely positioned relative to the
body.

As an added optimization, the browser could send an HTTP request
header like "Static-IDs" containing a list of the IDs of all <static>
elements currently on the page, so that the server can just leave
those empty.  A <dynamic id=foo> tag might be useful too, to indicate
that specific parts of a <static> element might indeed change -- in
this case the <static> element might have to be redrawn, but only once
the new <dynamic> element was fully parsed, not before.

I doubt this is suitable for HTML5, given how far along that is, but
it might be interesting to consider anyway.  Does the idea sound
interesting to anyone else?
Received on Friday, 16 October 2009 03:33:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC