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

On Fri, Oct 16, 2009 at 8:50 AM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> 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.

Indeed, script changes should persist.  The problem he was
highlighting, though, was the fact that a 'site bug' like that would
be very easy to have happen accidentally.  It could even go unnoticed
by the site developers, if they always come in through the front page
and the content is correct there - only users following search engine
links or bookmarks deep into the site would see the obsolete content,
and it would *never go away* during that browsing session.

This error seems like it would be very easy to make.

As well, this still doesn't answer the question of what to do with
script links between the static content and the original page, like
event listeners placed on content within the <static>.  Do they get
preserved?  How would that work?  If they don't, then some of the
benefit of 'static' content is lost, since it will be inoperable for a
moment after each pageload while the JS reinitializes.

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

I would hope that authors never did that!  That means that if a user
deeplinks straight into the site, they'll get the empty element.  The
hash won't help them, since it's their first pageview.  *Hopefully*
they'll swing by a page that has the actual contents and the hashfail
would trigger an update, but that's not a guarantee, and in the
meantime they have an empty element there.

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

I think being updated is more important than persisting changes to
(now out-of-date) content.

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

One of the big reasons Gmail is so AJAXy is because of the heavy
script lifting it has to do on each page load.  AJAX lets them persist
the script while updating the content.  <static> wouldn't help with
that.

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

The new page can just js-manipulate the static element.  If you're not
happy with that, then you really *do* need the bits to reload with the
page, and shouldn't be using <static>.

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

Only for the first pageload.  After that it's a persistent connection
- the iframe is just kept around while the outer page refreshes around
it.

And separate pages for each interface widget isn't bad.  Heck, it's
easier to maintain with everything self-contained.

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

True.  Minting a new element might be a better deal here, but having
it inherit much of the semantics of <iframe seamless>.  Then you can
have it contain fallback content for browsers that don't implement
<static>, and use @src for browsers that do.  That would also allow us
to bypass any of the <iframe> complications that might unnecessarily
complicate use or implementation.

~TJ

Received on Friday, 16 October 2009 07:16:21 UTC