W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2012

Re: [dom] Should the return values of getElementsByClassName/TagName/TagNameNS be HTMLCollection

From: Jonas Sicking <jonas@sicking.cc>
Date: Sat, 18 Feb 2012 04:00:00 -0500
Message-ID: <CA+c2ei8E09Yk+X_bw0VUz223jrn1DSJSfwb+6+eoNZmfOgAciw@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Ryosuke Niwa <rniwa@webkit.org>, Boris Zbarsky <bzbarsky@mit.edu>, www-dom@w3.org
On Sat, Feb 18, 2012 at 3:28 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Sat, 18 Feb 2012 09:17:52 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
>> I really think that the whole named getter issue is something that we
>> should not take lightly. It has many similarities with the scope chain
>> issue for on* attributes in that it causes namespace collisions making
>> it hard to add features in the future.
>> It seems to me that we should at least try to avoid propagating the
>> named getter behavior any further, and ideally try to actively
>> deprecate it to see if it's possible.
> Named getters are nice for authors,

I'm all for having convenient syntax. However we should do so in a way
that ensure that we don't collide with future expansions that we might
want to do. I.e. we shouldn't mix named getters on objects that also
have "built in" functions/attributes.

> and besides, it was already pointed out
> it's not avoidable here:
> http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0008.html

If we have to support it on getElementsByTagName then so be it. That
doesn't mean we have to spread the pattern to more places. For example
getElementsByClassName seems new enough that we don't need to support
it there. Likewise things like tableElement.rows and many other
collections where gecko currently supports named getters.

/ Jonas
Received on Saturday, 18 February 2012 09:01:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:18 UTC