[whatwg] hashchange only dispatched in history traversal

Wed Aug 15 05:30:05 PDT 2007

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.
> > >
> > > addEventListener("fragmentidentifierchange" doesn't seem too bad to me.
> > >
> > > And, if for some reason you wanted it shortened in your script, you
> > > could just do:
> > >
> > > var hashchange = "fragmentidentifierchange";
> > > a.addEventListener(hashchange
> > > b.addEventListener(hashchange
> > > c.addEventListener(hashchange
> >
> > I don't know.
> >
> >    <body onfragmentidentifierchange="">
> >
> > ...seems a bit overly long to me, still.
>
> True. As an attribute with the "on" part, it looks pretty bad.

I've always referred to fragment indentifiers as in-page anchors. So, why not:

<body onanchorchange="">

I think it's more readable than onfragmentidentifierchange

There is an HTMLCollection anchors that only lists <a name="">
elements. Extending the link-anchor metaphor into Javascript, the
fragment identifier anchors a DOM state. When a fragment identifier
changes, the anchor of the DOM state changes.

Regards,

Leons Petrazickis
Database Technology Advocate, IBM
http://lpetr.org/blog/