[whatwg] getElementsByClassName()

On 2/4/06, Jim Ley <jim.ley at gmail.com> wrote:
> On 2/4/06, Brad Fults <bfults at gmail.com> wrote:
> > I can't believe that you're so insistent upon this extremely narrow
> > set of use cases and that there aren't any other popular use cases for
> > getElementsByClassName().
>
> It's the only one that's ever been voiced without the extreme
> prompting now generating some.    The WHAT specifications (like the W3
> specifications, indeed most specifications) are creating features, and
> never voicing why they're necessary, the use cases are simply not made
> - there probably are use cases for them, but they _must_ be voiced,
> otherwise you simply cannot review them.
>
> > The requirement for a loaded document is to be expected when one
> > wishes to manipulate the constructed DOM from that document.
>
> No such requirement exists in web-browsers today, why are you suddenly
> inventing it?

My mistake. Replace "document" with "element" and you'll have my
intended meaning. That's not a suddenly invented requirement, as is
demonstrated with both getElementById() and getElementsByTagName().

> > I want my designer to be able to specify an arbitrary set of elements
> > in the markup for a web app that are to be "widgets". Now if the web
> > app is sent out to a client that supports function X, I want to
> > construct this X-widget around each of the elements in the set
> > previously defined.
>
> This use case is fulfilled by the -moz-binding and similar proposals,
> it does this more successfully (as it does not lead to the
> inconsistent UI problem)  I don't see the point in having both
> className selectors and -moz-binding XBL approaches,

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 utility and power of getElementsByClassName() is derived from the
same exact vein that both getElementById() and getElementsByTagName()
derive theirs. 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*. Your elusive use case already
exists in the use and abuse of the other two aforementioned functions.

Now if you want to debate the utility of either of these two existing
DOM functions, I think you will meet a much larger and strongly
opposed group of authors who depend on and use getElementById() and
getElementsByTagName() on a daily basis.

The reasons why XBL is not currently an acceptable substitute are
numerous, including its extremely limited implementation, its separate
and higher learning curve, and the fact that it doesn't hurt anyone to
have two methods to accomplish similar tasks, especially when one of
them lies within a completely different tool set.

> but thanks for
> the details.

Furthermore, your haughty and dismissive tone is neither appreciated
nor necessary in a discussion such as this.

> > Now that we can get past "why" we're specifying such a function, I
> > feel the need to reiterate the constraints on its specification,
>
> but we can't know the constraints until we know why we're specifying it...
>
> > 2. getElementsByClassName() must be *binding language* agnostic. That
> > is, we cannot assume that it will only be used in JS.
>
> I don't agree that it's necessary to do this, one of the historic
> problems of the DOM in the ECMAScript context (and others) is that
> individual language strenghts are not gained.  There is nothing
> obviously wrong with having language specific API's.

I agree. However, as far as I'm aware, we're not defining a binding
language API, but rather the core DOM components to which such an API
would provide a language-specific interface.

> > If getElementsByClassName() receives an array (synonymous with list),
> > which all binding languages I am aware of are capable of supplying,
>
> Do some binding languages not require the type of the parameter to be
> specified as either an array or a string?

I presume that all binding languages considered can either accomplish
method overloading or else use dynamic typing, either of which would
make this possible. If there are cases where this is not true, let
them be stated and then further examined here. Without such cases I
will continue to (reasonably) assume that any binding languages will
be able to deliver this functionality.

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

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.

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. I suggest you either take that specific issue up with him (seeing
as though he's both the WHAT spokesman and on the CSS WG) or raise it
as a separate issue on this mailing list (like it has been before).

Thanks.

--
Brad Fults
NeatBox

Received on Saturday, 4 February 2006 12:04:59 UTC