- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 16 Oct 2009 09:50:04 -0400
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.
Received on Friday, 16 October 2009 06:50:04 UTC