[whatwg] hashchange only dispatched in history traversal

Thu Aug 21 21:04:47 PDT 2008

On Thu, Aug 21, 2008 at 4:09 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 21 Aug 2008, Garrett Smith wrote:
>>
>> 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?
>
> I'm not sure what you mean. In HTML5, all event handler _attributes_ can
> be placed on any element, but that doesn't mean that the event will be
> fired by the UA at any element. The spec only fires the event at the body
> element.
>

The spec fires an event at the body element? LOL What does that mean?
Can you explian this using standard terms like "currentTarget" and
"thisArg"?

That's funny.

Detecting support for events is painful.  Detecting hashchange events,
given the current design, will be very painful.

>
>> "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?
>
> Yes, but the benefit of being able to do <body onhashchange=""> outweighs

What benefit?

> the logicalness of dispatching events to the Location object.
>

The design association of Location ---> LocationEvents

would seem to make browser scripting very easy. Once a location object
is obtained, it can be assumed to behave the way all location objects
behave. That would mean that it might be a fair inference to test:

if(location.addEventListener),

but that might be too loose an inference. A more thorough approach would be:-

var EventSupport = {};
if(location.addEventListener) {
(function(){
 var es = EventSupport;
 // Initialize the touch and gesture properties.
 es.location = hasSupport("LocationEvent");

 function hasSupport(s){
  try {
    document.createEvent(s);
    return true;
   } catch (e) {
     return false;
  }
 }
})();
}

>
>> >> 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="...">.
>>

That precludes the ability that hashchange would ever be supported on
body element. What's worse, the body element is far removed from the
event. It's not clear what the event target is or what the
event.target should be when the event fires. It is unclear what the
thisArg will be. The body is a child of the documentElement, which is
a child of the document, which is a property of the window.  It's far
removed.

Body's event handlers propagating to window worked in legacy browsers.
These browsers had such bararic APIs that design didn't matter. Demand
changed, browsers changed. Modern browsers are rich enough to
accommodate rich browser side applications and the trend forwards is
towards richer and richer functionality. API design matters more.

>
>> 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?
>
> Yeah, this is an open issue. I'm hoping that the DOM Events spec handles
> it.
>

Hoping? Why?

Creating ambiguous, illogical, confusing programming constructs is bad.

Such features will get used and the ambiguity will be realized in
implementations and with less careful, less knowledgeable developers
who did not memorize the complexities of an ambiguous API.

Such practices can be deprecated and discouraged in favor of features
that work better. This can be effective and <font> is good evidence.
Not much new code uses <font> because we have CSS working. This type
of new bad feature seems to be something that should be considered.
Hindsight is always better and retrospectively, we can see things that
the earlier specs got wrong. Using tests to write out proposals would
be a way to avoid this. For example, for hashchange feature, a test
could be wrote. it would fail, but we would see the design of the API.
>From there, we could hack up a poll function using setInterval, and
with that, we could see the effect of how the API would work. It's
more work, but would seem to be worthwhile insurance.

>
>> 1) add a note about bubbling. hashchange events bubble
>
> Per the spec, it doesnt.
>
Ah, but per MSDN, it does.
http://msdn.microsoft.com/en-us/library/cc288209(VS.85).aspx

Specifying this in a different manner than the way it is specified in
MSDN is a good way to make browser scripting more difficult.

IE's hashchange bubbles.

Was this considered?

>
>> 2) replace the "fires at the body element" with "the EventTarget fires
>> the event"
>
> I disagree with this interpretation of the terminology.
>

Then can you write something using standard terminology? I really
don't know what "fires at the [xxx] means."

Thanks.

Garrett

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