[whatwg] No interface flicker across page loads, without JavaScript

On Fri, 16 Oct 2009, Aryeh Gregor wrote:
> 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?

It sounds rather scary. :-)

This is definitely something for which I'd be looking towards experimental 
implementations as a guide as to the feasibility, rather than speccing it 
cold. Doing anything with the parsing, especially moving elements from one 
page to another, is very dodgy, especially when you consider what that 
means to the original DOM (which other scripts might still have references 
to, and which might be shown again if the user hits "Back").


On Fri, 16 Oct 2009, Markus Ernst wrote:
> 
> [...] 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.
> 
> 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.

Sharing documents across multiple browsing contexts is even more scary -- 
consider what happens to scripts who try to compare the "window" object.


On Fri, 16 Oct 2009, Aryeh Gregor wrote:
> 
> 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.

Why can't we just use AJAX, and not reload the page at all, for this?


> 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.

It's not clear to me why GMail would get rid of the AJAXness -- what 
problem would we be solving? Also, with AJAX you can do things like 
transitions, which you couldn't do with page loads.


> 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.

These all sound like things better addressed just by scripting and XHR.


On Fri, 16 Oct 2009, Tab Atkins Jr. wrote:
> 
> I would hope that authors never did that!

If there's one thing I've learnt from this work, it's that you can rely on 
authors doing everything you'd expect them to never consider.


On Fri, 16 Oct 2009, Aryeh Gregor wrote:
> 
> So, here's a preliminary description of a use-case.  I'm not sure it's 
> sane yet.
> 
> Use Case: A page should be able to instruct that when a user follows a 
> link, only part of the page is reloaded, while the rest stays fixed.

That's not a use case, it's a feature description. The use case is the 
_why_ -- what is the problem being solved?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 18 October 2009 02:19:11 UTC