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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 18 Oct 2009 14:38:12 -0500
Message-ID: <dd0fbad0910181238n3b36b751g3789f55c3637ef8e@mail.gmail.com>
On Sun, Oct 18, 2009 at 1:00 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> a) Avoiding flickering and jumping on page load.
> b) Saving bandwidth.
> c) Being able to preserve state of some parts of the page (e.g.,
> navigation collapse state) when others change (e.g., new content
> loaded).

I intend to solve a combination of (a) and (c) (b might be an
ancillary benefit, however).

Basically, there are two classes of websites who I think will benefit from this.

1. Fairly ordinary sites which have heavy widgetry in their skeleton.
These might be js-based (good semantic scripting often involves
sending something over the wire that's simple and accessible, then
substantially transforming it with js on the client to something more
useful/dynamic), flash-based, or something else entirely.  The idea is
that there are things which are expensive to initialize (in cpu, time,
whatever) that are present on every page.

2. Relatively simple single-page apps.  Something on the scale of
gmail probably won't be able to use this, and that's fine; they're
already making a significant js investment and can afford a bit more
to handle their single-pageness themselves, plus html5 will add
several features to make this easier.  However, a simpler mail client
may benefit significantly from this, as it eliminates a big chunk of
necessary js.  Other apps that have complex scripts that should
maintain their state may benefit too.  The idea here is similar in
that there may be a significant blob of js state that is expensive to
initialize or reload.

Really simple sites with static sections that are *actually* static
won't really see much benefit (the decrease in flickering may be
useful, but it's such a minor benefit that it's not worth engineering
towards).  As well, very complex js-driven applications will have more
complex requirements than can be met by this mechanism, and so won't
benefit from it.  But the middle ground I outlined above has
significant ability to grow, and I think is currently being held back
by the architecture of the web (where every page is a completely
independent resource) and the difficulty/expense of routing around it
with js.

~TJ
Received on Sunday, 18 October 2009 12:38:12 UTC

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