[whatwg] hashchange only dispatched in history traversal

Tue Aug 19 18:13:54 PDT 2008

On Wed, 15 Aug 2007, Leons Petrazickis wrote:
> On 8/15/07, Michael A. Puls II <shadow2531 at gmail.com> wrote:
> > On 8/14/07, Ian Hickson <ian at hixie.ch> wrote:
> > > On Sat, 11 Aug 2007, Michael A. Puls II wrote:
> > > >
> > > > I like "hashchange" even if it's not perfectly descriptive.
> > > >
> > > > However, "fragmentidentifierchange" although long, isn't much 
> > > > longer than DOMAttributeModified and is shorter than say, 
> > > > DOMNodeRemovedFromDocument.
> 
> I've always referred to fragment indentifiers as in-page anchors. So, 
> why not:
> 
> <body onanchorchange="">
> 
> I think it's more readable than onfragmentidentifierchange

We ended up using onhashchange="".

On Wed, 15 Aug 2007, Agustín wrote:
> 
> There are interesting cases to think of: what happens with anchors which 
> are not handled by the application? The browser won't know that and will 
> probably store the "404 not found error" equivalent page in the location 
> bar autocomplete history. How could this be handled? This problem 
> doesn't exist just for anchorchange events, since the non-existing 
> location might be the first url the user visits and then there would be 
> no opportunity to notify the browser that the url is invalid. Perhaps 
> this could be handled by adding some method in the "history" object. 
> Anyway, I guess that we can live without this.

We can get around this using location.replace() and some JS. That's how 
http://whatwg.org/html5 handles redirects when you give fragment 
identifiers from other pages in the multipge doc, for example.

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