[whatwg] <a onlyreplace>

[Schuyler Duveen]

Tab Atkins Jr. wrote:
> On Sun, Oct 18, 2009 at 11:20 AM, Schuyler Duveen
> <whatwg at graffitiweb.org> wrote:
>> Nelson Menezes wrote:
>> 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.)
I like the first one.  I'd rather it be on the document (or window) so
we don't have to wait for the first instance of an element to show up.

More importantly, then I can write javascript that's more generic rather
having to know about which specific elements will be doing the
loading/unloading in a particular document.

>> 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.
The problem is that people will make links that refresh different parts
of a document, to the point that the current document is no longer
addressable.  Use cases for this happen often enough (not necessarily
good design, but people will do this)

In the past, a good way to give (back) addressability to users is with
hash tags.  But here, the location changes, and the hash goes away.
Standard anchor tags (with no javascript) have generally been
addressable to users by default.  When this hasn't been true, like with
framesets, lots of confusion and frustration ensues.

If this is, in the longterm, going to work non-dynamically, then things
should be addressable by default.  It's one of the killer features of
the web :-)

/skjy

> 
> ~TJ
>