[whatwg] Use cases for Node.getElementById

[Calogero Alex Baldacchino]

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
>
> Element.getElementsByName.
>
> 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?
>
> Garrett
>   
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 
HTMLElement interface).

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

Best regards,
Alex
 
 
 --
 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
 
 Sponsor:
 RC Auto?
* Con Direct Line garanzia furto e incendio a soli 30 € per un anno! Non perdere l’occasione!
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8497&d=10-12