- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 20 Aug 2008 01:13:54 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 19 August 2008 18:13:54 UTC