[whatwg] several messages about an event for when the #fragid changes

Thu Aug 9 18:26:42 PDT 2007

On Tue, 28 Feb 2006, Loune wrote:
> 
> I don't know if this has been addressed or not, since I only briefly 
> scanned the spec. Hopefully, I didn't write this for nothing :) This 
> relates to the handling of anchors in URLs:
> 
> 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. 
> Traditionally, the suffixes are used to jump to the location which the 
> invisible anchor is located.
> 
> My proposal is to extend anchoring into a scriptable feature with the 
> addition of the anchor DOM Event. The anchor event will be fired every 
> time the page URL stays the same but the anchor suffix of the URL 
> changes. This basically includes:
> - Back and Forward navigation of anchors
> - Manually typing a URL/Loading from a bookmark
> 
> This is not unlike typical GET query strings where the portion after ? 
> are variables passed to the same script on the server, with the main 
> difference here being that this acts as a client-side query string. The 
> anchor event will be used to perform an action by the JS on the same 
> page.
> 
> What the event interface could look like: [...]
> 
> Flow of events:
> - When the page is loaded, and an anchor event listener exists, the 
> anchor event will be fired after the load event. If there is no anchor 
> in the URL, the event.anchorName property will be an empty string.
>
> - When an anchor link is clicked, the anchor event listener (if exists) 
> will be fired
>
> - The event handler can get the name of the anchor via event.anchorName 
> (which will contain the string after the hash)
>
> - If the return value from the handler is true, the traditional form of 
> operation (the jumping to the anchor) will occur next; otherwise, that 
> step is skipped.
>
> - The UA should act as if the navigation has gone forward a page (add 
> history, etc).
>
> - If the user navigates back and the previous page happens to be the 
> same page but a different anchor, the anchor event again will be fired 
> as if the previous anchor was freshly navigated to. The same logic 
> applies to navigating forward.
> 
> What this achieves:
> With the anchor event handling implemented in a webpage, the page can 
> now react to backwards and forwards events of the browser, without 
> having to reload the whole page. The user can also bookmark a specific 
> state of the page, as specified in the URL.

Since you can already catch loads and unloads, the key part of this 
proposal that seems useful is the catching of fragment identifier changes. 
I've added an event (hashchanged) that fires when that happens.

On Wed, 1 Mar 2006, ROBO Design wrote:
> 
> Yet, as I see it, your suggestion is more elegant and easier to use. The 
> state objects defined by WA 1.0 are very good, but they might be "way 
> too much" for simple usage.

The spec has both now.

On Thu, 2 Mar 2006, Ric Hardacre wrote:
> 
> to clarify, where would the event be attached by default? document or window?
> i.e. would i
> 
> function myonAnchor( e )
> {
> 	if( e.anchorName )
> 	switch( e.anchorName )
> 	{
> 
> 	...
> 
> 	default:
> 		return true;
> 	}
> }
> 
> document.onAnchor = myonAnchor;

It'll be on <body>, the same way as onload, onunload, etc. (The exact 
mechanics of that still need to be defined, actually, for all these 
semi-magical <body>/window events.)

On Wed, 8 Mar 2006, Loune wrote:
> 
> I've had a look at the "Session history and navigation" state spec and 
> if I'm interpreting it correctly, it only solves part of the problem.
> 
> Using state objects you would:
> 1) Implement the popstate event
> 2) use the window.pushState(stateobject) to push the state into the "state
> stack?"
> 3) When user navigates back, popstate event fires with the state object
> 
> From the terminology, I gather that once you popped the state, you don't 
> have the state in your history anymore?

This is incorrect; the state object stays in the history. You can go 
backwards and forwards.

> That means after you navigate back, you can't go forwards again. The 
> state spec also leaves room for a URI to be associated with the state. 
> But it begs the question of how will the URI be correlated to the state 
> DOMObject in way that the URI can restore the state, even if the URI is 
> posted to a web page, or sent via email to a friend.

That's up to the server.

> I think the two specs, onanchor/state can be reconciled. The traditional 
> anchor jumping could be made a behaviour of a modified state spec. Each 
> jump will be regarded as a new state of page in the session history. It 
> will however need some modifications for it to be able to perform like 
> it is on current browsers (going forward, URL change, scrolling).

Indeed, what I did was take your event idea and make it happen at the end 
of the history traversal step.

On Wed, 8 Mar 2006, Johan Sundström wrote:
> 
> +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.

I'm not sure what it would mean to cancel it. Could you elaborate on this?

> 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.

As far as I can determine, .watch() is a Gecko-specific feature. It's not 
clear to me how it is supposed to interact with the other features like 
session history traversal.

On Sat, 23 Jun 2007, Agustín Fernández wrote:
>
> There is currently no way to detect a change in the url of a page other 
> than polling for changes in document.location.hash all the time (which 
> is slow and potentially complex, and doesn't always work in IE -) or 
> listening for click events on all links (which doesn't catch changes not 
> started by clicking on links -such as clicking back and forward, or 
> changing the hash by hand-).
> 
> Changing the hash in a page is useful to provide bookmarks and back and 
> forward functionality in ajax driven web applications which never fetch 
> a new page and is used extensively in the web.
> 
> I propose an urlchange (urlhashchange? hashchange? locationchange?) 
> event which would be dispatched by the BODY element whenever the hash 
> portion of the url changes.

I used your suggested name (hashchanged).

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'