[whatwg] hashchange only dispatched in history traversal

Thu Aug 21 11:18:08 PDT 2008

On Wed, Aug 20, 2008 at 11:00 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 20 Aug 2008, Garrett Smith wrote:
>>
>> 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?
>
> Yes.

I see that in MSDN now that hashchange applies to (window, BODY, FRAMESET).

HTML 5 expands "hashchange" to any element. Any element, such as div
or pre? How can you know if an element supports "hashchange" or not?
"hashchange" seems closely related to the Location interface, so it
would seem to make sense to have "hashchange" implemented for objects
that implement Location.

Has this been considered?

This would make it easier to know which elements support hashchange
events (body doesn't really support the event, it's just a pass-thru).

It would make the most sense to have hashchange *on* the Location, e.g.

location.addEventListener('hashchange', cb, false);

- but that would not be compatible with IE.

>
>
>> I'm not sure what that has to do with the body element.
>
> Nothing especially, except that that is where the event is fired, so that
> you can do <body onhashchange="...">.
>

 "fires at the body element"  sounds as if the event is firing itself,
at the body. Instead, say the EventTarget fires the event. For
example: "The window fires the hashchange event."

Body event handler attributes cascading to window is unclear and
creates ambiguity as to what the event is being attached to.

<body onmousedown="alert(this)">

alerts "window" in Firefox 3. The mousedown event fires anywhere, not
just on the body. This creates ambiguity. So it is a practice that
should be avoided in attempt to be cross browser. Has this problem
been considered?

1) add a note about bubbling. hashchange events bubble
2) replace the "fires at the body element" with "the EventTarget fires
the event"

Garrett

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL