[whatwg] hashchange only dispatched in history traversal
ian at hixie.ch
Fri Aug 10 12:35:20 PDT 2007
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
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_:
...and shortening it:
...leads to something that isn't IMHO that much clearer or better than
what we have now:
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg