- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 18 Oct 2009 11:28:26 -0500
On Sun, Oct 18, 2009 at 11:20 AM, Schuyler Duveen <whatwg at graffitiweb.org> wrote: > Nelson Menezes wrote: >> 2009/10/18 Ian Hickson <ian at hixie.ch>: >> >>> On Sat, 17 Oct 2009, Schuyler Duveen wrote: >>>> One of the big issues we found using it on some other sites is that >>>> javascript listeners (rather than onclick="" attributes), and other DOM >>>> pointers in the system became stale. ?Thus, only half the problem was >>>> solved. >> >> Well, you are effectively destroying and regenerating parts of your >> DOM so whatever JS event handlers you have in place need to be updated >> on refresh. That is no different from what happens today with AJAX, or >> indeed multi-frame JS. > My point (which feeds on Marcus Ernst's point) is that we need some kind > of load event. ?Maybe something like: > document.addEventListener('replaceonly') > with the event object providing access to the new DOM content and the > old DOM node. I agree, though I think it might be better to follow the current load/unload model with a replaceUnload/replaceLoad event being fired at the appropriate elements. (Or, as was suggested by someone else, just using load/unload on a particular element, since currently it just fires at window. I don't know if there are inherent problems with this or what.) >> The possibility remains to use partial content responses to optimise >> resource usage (via the proposed "onlyreplace" HTTP header), but the >> point of this proposal is that it makes it easy to address the >> no-UI-refresh requirement without a complex server- and client-side >> framework, and offers transparent fallback. It is not so much that >> this can't be done today (it can) but that we would standardise and >> promote the way to do it right. > > I like this idea a lot. ?It seems like a job for the HTTP Content-Range > header (using a different word than 'bytes'). Yup, something like this should emerge at some point. > One other thought: > It might be a good idea to allow the server to explicitly demand a full > load. ?(I.e. a server-side equivalent to window.top=location) Ah, interesting, a response header that says "I know you only asked me for certain parts of the response, but here's the whole thing instead, and please load it all". > There's still seems like a big danger in addressability. ?Yes, it's a > problem in ajax, but it's a problem that authors can solve on their own > with hash tags (in ad-hoc ways). ?When the browser takes over the > location value, the author's ability to do that is undermined. ?Maybe it > should all *stay* in the hash tags like your implementation has it. > > Something like: > http://example.com/#id1=page2;id2=page3; > where the value is the most recent source URL for that @id. Well, the point is that this should generally act as just an optimization of normal navigation. Clicking on <a href=foo onlyreplace=bar> should give you the same result as clicking on <a href=foo>, just without the overall page getting flushed. So the address should update to "http://example.com/foo", etc. You can always url-hack on your own, if you need to. ~TJ
Received on Sunday, 18 October 2009 09:28:26 UTC