I am very disappointed. "onhashchange" intuitively means that the content hash changes (which is more or less equivalent to modifying the content, of course). I would call this event "onreveal" to be in line with the primary bookmark semantics. The name is inspired by the Finder AppleScript dictionary, of course. Please reconsider. Chris
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, August 20, 2008 3:14 AM To: Leons Petrazickis; Agustín Cc: Michael A. Puls II; WHATWG; Maciej Stachowiak Subject: Re: [whatwg] hashchange only dispatched in history traversal On Wed, 15 Aug 2007, Leons Petrazickis wrote: > On 8/15/07, Michael A. Puls II <[EMAIL PROTECTED]> wrote: > > On 8/14/07, Ian Hickson <[EMAIL PROTECTED]> 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="".