[whatwg] getElementsByClassName()

[Jim Ley]

On 2/3/06, Gervase Markham <gerv at mozilla.org> wrote:
> Jim Ley wrote:
> > Yes, but they're all using it to attach events to every one of the
> > class, which is why you have to look at use cases, the reason they're
> > doing it is not because getElementsByClassName is missing, but because
> > addEventListenerToClass or -moz-binding etc. are missing.
>
> But why implement addEventListenerToClass() when you could implement
> getElementsByClassName(), which has a far more general utility? As soon
> as a single non-event-listener-related application comes along, you find
> you've implemented the wrong thing.

Er, no the use case people have is that they want everything that has
class X to respond to a particular event, if you model that with
getElementsByClassName then you cannot change a class on an element
and have it respond, without re-running the attachment, and manage the
fact you've already attached it to some classes etc.

It does not simplify the situation at all.  It can also only happen
once the element with the class is available, that fails the
consistency of UI axiom, since your element will respond differently
after the function has run.

> Here's a use case, then: the about:license document I just checked into
> the Mozilla codebase. When the page is called with the spelling
> "about:licence" instead of "about:license", I use
> getElementsByClassName() to search for elements with the class
> "correctme", and do a search and replace within them to correct the
> spelling. However, I can't correct it everywhere as I shouldn't be
> mutating legal documents. But I can do it in commentary, titles,
> contents and so on.

What an extremely odd use case, but it is at least a use case,
thankyou.  I'm not sure it's really one significant enough to warrant
implementing it given the large number of other methods of achieving
the same spelling correction.  Especially as the majority of them can
be done without requiring javascript at all.

Jim.