[whatwg] <a onlyreplace>
Tab Atkins Jr.
jackalmage at gmail.com
Sun Oct 18 09:28:26 PDT 2009
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
>>>> pointers in the system became stale. Thus, only half the problem was
>> 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:
> 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:
> 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.
More information about the whatwg