[whatwg] Use cases for Node.getElementById
Calogero Alex Baldacchino
alex.baldacchino at email.it
Wed Dec 10 08:10:06 PST 2008
Garrett Smith ha scritto:
> On Sat, Dec 6, 2008 at 7:09 PM, Calogero Alex Baldacchino
> <alex.baldacchino at email.it> wrote:
>> Simon Pieters ha scritto:
>>> On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino
>>> <alex.baldacchino at email.it> wrote:
>>> (I'm currently the editor of that proposal, currently located at
>>> http://simon.html5.org/specs/web-dom-core )
>> I'm reading it :-)
>> And I have a few questions.
> I did not see a proposal for Element.getElementById.
> I would not care about that much.
> I woud rather have
> It is perfectly valid for a doucment to have multiple elements w/the
> same name (though not generally a good idea). I've seen this before.
> Was this proposed?
I don't remember what spec exactly stated this first, but I remind of a
previous HTML version declaring the 'name' attribute as unique in the
'global scope' (or something like that), meaning the whole document;
then, I remember 'name' was deprecated in favour of 'id'. I think
'getElementsByName' was retained from the past just because form
elements scoped input names in a different manner (while the name of an
anchor, for instance, had to be unique in the whole document), but it
was a bit conflicting with the uniqueness of (at least some) elements'
name. Anyway, this is what I remember (current specification no more
defines a name attribute for every elements - it's not on the
However, the issue about Node.getElementById originated by noticing
problems with duplicate ids in existing pages and the likelihood new
pages may have duplicate ids (e.g. by repeatedly cloning and inserting
nodes without caring of all attributes), thinking on the opportunity to
address such an illegal state somehow. If non-unique identifiers have to
be a deliberate and 'careful' choise, such to involve a dedicated
attribute, perhaps the class attribute and [ HTMLDocument | HTMLElement
| whatever_else_implementing ].getElementsByClassName() methods can
address that: classes are non-unique not only for the whole document,
but also for the same element, which may have multiple classes listed in
its attribute (each class name is unique in the list), so they might be
used for some non-style-related purposes, just appending a name to the
list of styling classes (just to give some clearness, though
unnecessary), and querying it with getElementsByClassName() would work
the same way as resorting to the 'name' attribute and the
'getElementsByName()' method (perhaps a bit tricky, but should work fine).
@ Simon Pieters (and everyone else on the list, of course).
I was thinking again on 'getElementsByClassName()' moved to Web DOM
Core: maybe a good place for it might be the Node interface, so to have
the method working on Documents as well as on Elements; if the
HTMLCollection interface were moved as well, perhaps such might be the
return value, instead of a NodeList, since non-element Nodes should
never be expected to have a class name, I guess (perhaps doing the same
with getElementsByTagName might be consistent, but maybe problematic
because of backward compatibility -- while getElementsByClassName would
be a 'new entry' in the 'reign' of Core interfaces, thus a greater
degree of freedom might be taken, if reasonable, of course - it may
depend on a known need for different, specilized algorithms in Document
and Element nodes, for instance).
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
* Con Direct Line garanzia furto e incendio a soli 30 per un anno! Non perdere loccasione!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8497&d=10-12
More information about the whatwg