[whatwg] getElementsByClassName()

[Jim Ley]

On 2/4/06, Brad Fults <bfults at gmail.com> wrote:
> I fully admit the possibility that this may be better accomplished
> with some other theoretical and/or vendor-specific technology, but you
> again missed the core point.

the core point is we're inventing something new to meet a use case,
you invent the best thing to meet the use case, you don't invent
things that allow you to write loads more script to fulfil the use
case.  Of course if there were lots of use cases then the general is
good.

The problem is people on this list are continually inventing methods,
without considering the use cases, hopefully by forcing people to
voice the use case and defend it against superior, already implemented
technologies like -moz-binding will mean that people will give the
information first so we are actually able to evaluate their proposals.

You cannot evaluate a proposal without knowing the use case.

> If they are useful, then getElementsByClassName() is
> also useful because it gives an author *more control* over the DOM for
> solving the *same types of tasks*.

That is not immediately apparent, and neither is it apparent that a
classname specific shortname is worthwhile when a CSSSelector one
would be more appropriate.    You don't continually add methods,
methods are complexity, they need writing, they need testing etc.  you
have to have a reason to add a method.

> The reasons why XBL is not currently an acceptable substitute are
> numerous, including its extremely limited implementation,

So something with no implementation should be taken over something
with an existing implementation, that's pretty odd.

> its separate
> and higher learning curve, and the fact that it doesn't hurt anyone to
> have two methods to accomplish similar tasks,

It absolutely does hurt to increase complexity of implementations,
specifications and tests!

> > I do not personally see the use case for a class specific operator,
> > either a CSS Selector method, that selects on any CSS selector, or
> > nothing seems appropriate.
>
> With all due respect, whether you personally see the use case for a
> specific method to be defined for use by all web authors is largely
> irrelevant.

Well everyone's opinions on the list are largely irrelevant, the WHAT
individual has sole discretion of what goes in.

> If other authors and designers do see use cases and have
> concrete examples of where this function would add a great deal of
> power and flexibility to their tool set, it is worth consideration and
> design.

But a CSSSelector method has more power, not less, and adds little in
implementation complexity surely?

> It is unfair to the rest of the contributors to this specification and
> web authors in general to hold up the design and/or implementation of
> a (generally-agreed) useful tool due to simple personal differences in
> taste or opinion.

I'm not holding up anything?  This is not a democracy.  If you want a
quality specification though, you engage in debates with people who
have opposite ideas.  People have shown enough use cases that indicate
the ability to select elements by a css selector is a useful function
- they've not made the case to me at all that a class name specific
one is useful though.

> Ian has already indicated that the specification of a method to
> collect DOM elements based on a CSS selector is best left to the CSS
> WG.

Then why isn't className?  or why don't we just wait for that, having
both cssselector and classname is needless verbosity.  Whilst
implementation of ClassName is trivial if you CSSSelector, increasing
the memory footprint of a DOM is not useful to anyone, and a severe
limitation on getting it on many devices.

Jim.