[whatwg] hashchange only dispatched in history traversal

[Ian Hickson]

On Fri, 10 Aug 2007, Anne van Kesteren wrote:
>
> Wouldn't it make sense to dispatch the event whenever location.hash 
> changes value? When following a link for instance? (Unless I 
> misunderstood something it's currently only dispatched in history 
> traversal.)

History traversal happens as part of navigation.


On Fri, 10 Aug 2007, Maciej Stachowiak wrote:
> 
> I would also suggest calling it something other than hashchange. I 
> realize the term "hash" is used in other places in the HTML DOM to refer 
> to the fragment ID but it sounds weird in an event name like that. CSS 
> uses "target" and the URI RFC uses "fragment identifier".

"target" is far too overloaded in HTML and DOM to use here, IMHO (it means 
both DOM Event target and browsing context target during navigation -- 
both of which are actually relatively close to what we're talking about).

"fragment identifier" is what I originally was going to use as part of the 
event name. But the event name would be _long_:

   onfragmentidentifierchanged=""

...and shortening it:

   onfragidchanged=""

...leads to something that isn't IMHO that much clearer or better than 
what we have now:

   onhashchanged=""

The advantage of "hashchanged" is that it is very literal -- the attribute 
called "hash" changed just before the event fired.

But, I'm very open to changing the event name. What would you suggest?

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