[whatwg] hashchange only dispatched in history traversal

[Garrett Smith]

On Wed, Aug 20, 2008 at 4:50 PM, Ian Hickson <ian at hixie.ch> wrote:
>
> On Wed, 20 Aug 2008, Køi¹tof (R)elechovski wrote:
>>
>> 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.
>
> To reconsider we would need new information. As far as I know, no new
> information has come to light, so there's no reason to reopen the naming
> discussion.
>
>
> On Wed, 20 Aug 2008, Thomas Broyer wrote:
>> onlocationhashchange?
>> ...because it's fired when location.hash changes...
>>
>> (I have personally no problem with onhashchange)
>
> "onlocationhashchange" is too long. "onhashchanged" is referring to the
> "location.hash" attribute, and seems clear enough.
>
>
> On Wed, 20 Aug 2008, Garrett Smith wrote:
>>
>> What is this?
>
> Please search for "hashchange" in the HTML5 spec for details.
>
http://www.whatwg.org/specs/web-apps/current-work/#onhashchange
| onhashchange
|
|    Must be invoked whenever a hashchange event
| is targeted at or bubbles through the element.

I see it fires on History Traversal:
| If the specified entry has a URL that differs from the current entry's
| only by its fragment identifier, and the two share the same Document
| object, then fire a simple event with the name hashchange at the body
| element

Is 'hashchange' an event that fires every time window.location.hash changes?

I'm not sure what that has to do with the body element. This may be
one of those new ideas that may not ever see widespread
implementation. I'm interested in discussing the other issue that is
more relevant to existing standards and implementations
(Misconceptions Documented).

Garrett

> Cheers,
> --
> Ian Hickson               U+1047E