W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2006

[whatwg] anchor(jump) DOM Event proposal

From: Johan Sundström <oyasumi@gmail.com>
Date: Wed, 8 Mar 2006 14:49:03 +0100
Message-ID: <2de757660603080549j75784c1ep8ea4f44c7efeb45c@mail.gmail.com>
> A common argument or complaint against AJAX is that it renders the back
> and forward buttons useless and thereby interrupting the normal flow of
> browsing. It is also impossible to bookmark the state of the page [due
> to the URL remaining the same]. Normally, navigating to a new URL will
> result in the browser performing a new request to the server, but there
> is one exception to that - which is invoking an anchor via # suffix.

+1 for making this a DOM event you could preventDefault(), and which
would trigger not only on programmatic state change of
(window.)location.hash, but similarly on user change.

It's worth noting that for the typical case of listening in on
programmatic change of location.hash, there is the generic feature
inherited from Object.prototype.watch, which lets you not only watch
but also decide over what happens to the value on modification. Try
this bookmarklet on a page that sets location.hash to see the former
value, which value it gets changed to and lets you pick another one
instead:

javascript:void(location.watch('hash',function(a,b,c){return
prompt(a+':'+b,c);}))

I would not consider your suggestion a solution to the ajax REST
problem, though still useful for reacting to a bookmark trying to
initiate a specific page state without reloading the page, which is
something that just doesn't work RESTfully today.

--
 / Johan Sundstr?m, http://ecmanaut.blogspot.com/
Received on Wednesday, 8 March 2006 05:49:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:45 UTC