Re: [whatwg] No interface flicker across page loads, without JavaScript
On Sun, Oct 18, 2009 at 1:00 PM, Aryeh Gregor 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
Re: [whatwg] No interface flicker across page loads, without JavaScript
On Sun, Oct 18, 2009 at 5:19 AM, Ian Hickson wrote: > Why can't we just use AJAX, and not reload the page at all, for this? 1) AJAX is more difficult to set up, as far as I understand it. I can't say for sure, since I haven't ever tried to set up AJAX from scratch. 2) Getting bookmarkable/sharable URLs right requires extra effort with AJAX. Without HTML5 scripted history traversal (pushState, etc., IIRC -- I haven't looked at that yet, you know what I mean), it's not even possible to do it in a way that interoperates with non-JS UAs, like search engines following links that users have posted to forums. You have to store state in hashes, and reconstruct it using JS. 3) Getting fallback to non-JS UAs right requires you to write everything twice, pretty much. Or create a complicated framework that will automatically generate everything twice. In particular, search engines don't work well with AJAX at all. All I can say is that in practice, I've never even bothered looking at AJAX for page-reload situations (as opposed to performing actions within the current page) because it seems too complicated to do right. A simple method that would automatically fall back to full page retrieval would be much more attractive to me. > 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. I don't think Gmail specifically would get rid of AJAX. The feature described here is only useful for simple cases. It's not clear to me at this point whether it's a good enough tradeoff between simplicity and power to get significant uptake at all, let alone in sites with much more complicated needs. > 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? I'm not *entirely* sure, since I've never seen the need to use anything like this myself. The desired features seem to include: 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). Is the desirability of those three things clear enough for them to qualify as use cases? I don't know if the list is exhaustive. (a) seems to have some people (at least Tab) interested in the feature proposal for its sake alone. It's possible that (a) could best be solved by general adjustments to how browsers lay out pages, perhaps opt-in, but that's way beyond my field of expertise. The basic problem seems to be that on the one hand, browsers need to do progressive rendering so that the page is usable as quickly as possible; but on the other hand, this means they need to clear away the whole page, including parts that won't actually change. Some way of hinting that certain parts shouldn't be cleared away, or should be cleared away in a different manner, but *without* changing what will show up when the page is finally loaded, might be a better solution here. It might affect only presentation and be invisible even to scripts. (b) is probably the least important of the three features, and can be addressed by other means that might be more useful overall (like SDCH). Some of the proposals have incidentally included some features in this direction because they seemed simple to tack on. (c) looks like the part that really needs to be solved by something along the lines of the given proposals, if AJAX and frames (and saving state in cookies and recreating it on page load, etc.) are unacceptable for whatever reason. Frames have problems that are very well recognized. AJAX has at least the problems mentioned above. Saving and recreating state on page load is a pain, I guess, and it would be nicer if it were automatic. I'm not the best person to ask here, though. All I can say personally is that if a good, robust mechanism were developed along the lines I and others have described, that doesn't create the potential for scary random errors of various stripes, then I *might* use it. I wrote my proposal based on the discussion about frames -- "use AJAX" didn't seem acceptable to a lot of people in the discussion, for whatever reason. I'm not personally all that interested in this feature.
Re: [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 > 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: > > Some stuff that doesn't change on page load... > Changeable page content > Some more stuff that doesn't change... > > 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 > elements untouched, so they don't flicker or vanish. > 3) When parsing the page, if a element is reached that has > the same id as a element that was on the old page, ignore the > contents of the new one. Instead, move the old element to > the position of the new one, copying its DOM. If possible, this > shouldn't cause the visible 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 elements > currently on the page, so that the server can just leave those empty. > A tag might be useful too, to indicate that specific > parts of a element might indeed change -- in this case the > element might have to be redrawn, but only once the new > 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: > > I eat meat > > and links to page2.html, which contains: > > I am a vegetarian > > 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 element. But I assume an easier implementation would be > adding a "static" attribute for the 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 id=column-one> could be . (With a few exceptions, like 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 wor
Re: [whatwg] No interface flicker across page loads, without JavaScript (was: framesets)
On Fri, Oct 16, 2009 at 10:16 AM, Tab Atkins Jr. wrote: > 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. Hmm. Maybe. > 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 . 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. Script links should be preserved somehow, ideally. I would like to see this be along the lines of "AJAX reload of some page content, without JavaScript and with automatically working URLs". > 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. I meant in conjunction with an HTTP header the browser would send, like "Static-Hashes", that contains the hashes of all known elements. This is like the Static-IDs that I described in my first post. The idea would be that a script could chop out the unneeded parts on a per-request basis. However, I think SDCH is a better solution here. > I think being updated is more important than persisting changes to > (now out-of-date) content. It depends on how important the changes are. If for some reason you have a in , and the user has entered tons of text, saving it is fairly important. Although you should be able to hit "back" to retrieve it, actually, so maybe not *that* important. > 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. wouldn't help with > that. That's why script needs to persist. My initial proposal doesn't handle that well at all. > Only for the first pageload. The first page load is by far the most important. > And separate pages for each interface widget isn't bad. Heck, it's > easier to maintain with everything self-contained. Handling everything in one request is *much* simpler from the POV of server-side scripting. If it's separate requests, you can typically only communicate between them if you a database of some kind. That's a real pain. You're running several instances of the script which all need to produce consistent output, and that's a lot harder than if it's just one instance. What if different cookies end up being sent to different frames, for instance? That's very possible if the user gets logged out at some point, say. The new page load needs to be able to invalidate the other parts of the page somehow. > True. Minting a new element might be a better deal here, but having > it inherit much of the semantics of . Then you can > have it contain fallback content for browsers that don't implement > , and use @src for browsers that do. That would also allow us > to bypass any of the complications that might unnecessarily > complicate use or implementation. I still don't like the requirement for multiple pages. It might not be a big deal if you're dealing mainly with static content, but for complex server-side scripts I think it would be a real pain. 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. Requirements: 1) Little to no JavaScript should be required. Large JavaScript frameworks should not be necessary to get basic persistence of interface state. 2) Static parts of the page should not have their state discarded, either script-related state (e.g., registered event handlers) or other state (e.g., user-entered text). 3) It should be possible for user agents to implement the feature so that the static parts of the page don't flicker or jump around unless they've actually changed. (This might or might not be an actual conformance requirement, but it should be possible for them to do it if they want.) 4) It should be possible to easily attach this to an existing set of static pages, or JavaScript-light pages produced by a web application. Ideally, it should be possible to do by addi
Re: [whatwg] No interface flicker across page loads, without JavaScript (was: framesets)
On Fri, Oct 16, 2009 at 8:50 AM, Aryeh Gregor wrote: > On Fri, Oct 16, 2009 at 7:16 AM, Markus Ernst wrote: >> Interesting idea! Anyway it introduces some consistency problems to solve, >> e.g.: >> >> Page1.html contains: >> >> I eat meat >> >> and links to page2.html, which contains: >> >> I am a vegetarian >> >> 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 > . 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 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 . 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 instead, in the > serialized document passed over the wire. Bandwidth savings could > then be obtained using 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. 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 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 . >> 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 >> element. But I assume an easier implementation would be adding a >> "static" attribute for the 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 interfac
Re: [whatwg] No interface flicker across page loads, without JavaScript (was: framesets)
On Fri, Oct 16, 2009 at 7:16 AM, Markus Ernst wrote: > Interesting idea! Anyway it introduces some consistency problems to solve, > e.g.: > > Page1.html contains: > > I eat meat > > and links to page2.html, which contains: > > I am a vegetarian > > 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 . 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 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 instead, in the serialized document passed over the wire. Bandwidth savings could then be obtained using 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 could be . (With a few exceptions, like .) 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 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 > element. But I assume an easier implementation would be adding a > "static" attribute for the 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 . as I envisioned it can be dropped into existing pages without requiring them to be broken into separate files, or risking compatibility problems.
Re: [whatwg] No interface flicker across page loads, without JavaScript (was: framesets)
On Fri, Oct 16, 2009 at 6:16 AM, Markus Ernst wrote: > Aryeh Gregor schrieb: >> >> On Thu, Oct 15, 2009 at 3:49 AM, Nelson Menezes >> 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: >> >> Some stuff that doesn't change on page load... >> Changeable page content >> Some more stuff that doesn't change... > > Interesting idea! Anyway it introduces some consistency problems to solve, > e.g.: > > Page1.html contains: > > I eat meat > > and links to page2.html, which contains: > > I am a vegetarian > > 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. Nod. This seems like a big problem. > 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 > element. But I assume an easier implementation would be adding a > "static" attribute for the element, indicating that the iframe > contents should not be reloaded. As well, if is reused, it should probably automatically be so that all navigation applies to the upper page, it grabs styles from the upper page, etc. (Or perhaps it should just be recommended that be used in most circumstances.) The solution is also somewhat better wrt scripting the content inside. If you're trying not to redraw anything in , what happens to scripts that have added listeners and such to the content? (Frex, to implement an accordion or treeview.) The original page is going away, and you don't want to accidentally apply the listeners multiple times. Using s, you can do the scripting in the framed page, so nothing goes away between pageloads or tries to apply itself multiple times. ~TJ
Re: [whatwg] No interface flicker across page loads, without JavaScript (was: framesets)
Aryeh Gregor schrieb: On Thu, Oct 15, 2009 at 3:49 AM, Nelson Menezes 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: Some stuff that doesn't change on page load... Changeable page content Some more stuff that doesn't change... Interesting idea! Anyway it introduces some consistency problems to solve, e.g.: Page1.html contains: I eat meat and links to page2.html, which contains: I am a vegetarian 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 element. But I assume an easier implementation would be adding a "static" attribute for the element, indicating that the iframe contents should not be reloaded. -- Markus
