[whatwg] <a onlyreplace>

[Tab Atkins Jr.]

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