[whatwg] hashchange only dispatched in history traversal
ian at hixie.ch
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg