[whatwg] <a onlyreplace>

[Tab Atkins Jr.]

On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen
<whatwg at graffitiweb.org> wrote:
> 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.

As long as the event bubbles, you can always just listen at the
document root and then check event.target to see who got updated.
That way you don't have to wait, nor do you have to know which
specific bits are getting replaced.

>>> 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 :-)

You're right, and this makes me think more strongly that restricting
the ability to specify the replaceable bits to just <base> is the
right way to do this.

~TJ