- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sun, 18 Oct 2009 14:00:22 -0400
On Sun, Oct 18, 2009 at 5:19 AM, Ian Hickson <ian at hixie.ch> 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.
Received on Sunday, 18 October 2009 11:00:22 UTC