[whatwg] Use cases for Node.getElementById

[Calogero Alex Baldacchino]

João Eiras ha scritto:
>
> IMO, anyone suggesting a Node.getElementById clearly does not know 
> very well how getElementById is supposed to work.
> There are ways to transverse a DOM tree currently, either DOM 
> properties and methods, XPath, selectors API and such.
> Considering ids are required to be unique in the context of a single 
> document, implementations can, and do, implement id lookup using 
> optimized data structures like a hash table, which is much more 
> performant than doing transversal.
> So if there is a special node in a document, add an id to it and get 
> its reference will be performant (ideally O(1)).

Such a hash table cannot prevent at all the need of traversing the DOM 
tree for the purpose of a _correct_ implementation of .getElementById. A 
DOM tree is a live structure, so the hash table must be checked and 
updated each time a node is removed AND each time a node is inserted, 
for a couple of reasons, and such update may request some kind of tree 
traversing (i.e. to compare nodes relative position). Actually, 
getElementById is being defined as returning the _first_ element with a 
matching ID, as a graceful degradation in case of duplicate IDs and to 
give a better standard (= unique) definition of the expected behavior in 
front of duplicate IDs, than what stated in DOM 3 Core (which leaves 
such behavior unspecified -- it's said to be undefined -- and possibly 
implementation or document specific); this means that, upon insertion of 
a new element, this one might be the new 'first' element with a certain 
id, so its order must be checked and the hash table updated accordingly. 
When an element is removed, independently of the previous scenario, if 
it was in the hash table it might be just removed from the table a well, 
but such wouldn't work fine, because there might be a descendant, or an 
otherwise following element with the same id: after the removal, such 
element would pass from the 'illegal' state of being a duplicate-ID 
element, to the 'legal' state of being the current element to be 
returned by getElementById => the existence of such an element must be 
checked and the hash table updated accordingly. If there are far more 
insertions and/or removals of elements with the id attribute set, than 
calls to getElementById, the advantage of a live hash table vs 
traversing as needed can be quite lost; anyway, a traversal can be quite 
fast, especially if the DOM structure is implemented as a balanced 
binary tree (and I hope you don't wish to implement any kind of 
non-binary tree as the base tree structure).

>
> If the uniqueness requirement is removed, then getElementById looses 
> its whole meaning and should actually be removed from the 
> specification entirely, else then we would need more bloat like 
> getElementById or getElementListById and whatever.

Do you thing that getElementsByTagName and getElementsByClassName are 
bloaty and useless too? However, my point was, and is, another (I'm not 
for Node.getElementById - nor I am strongly against it).

>
> If you really need to get the element with id in a subtree, connected 
> or disconnected from the main tree, one can use selectors API, DOM 
> transversal, XPath, etc.

Currently, the id uniqueness is defined such as constraining not only a 
whole document, but also a disconnected subtree. Then, what API is such 
constraint relevant for? If none, is it worth to declare such constraint 
for disconnected subtrees? Or, is there any need for an API directly 
handling IDs in disconnected subtrees?

In other words, what's being constrained by the id uniqueness in a 
disconnected subtree? A disconnected subtree may be a subtree of another 
document, different from the one currently handled by a script; in this 
case, the id uniqueness is relevant for the actual document containing 
the subtree (while any other document shouldn't be affected by 
cross-document IDs clashes). Otherwise, it may be a subtree external to 
any document, and in such case, perhaps, it might be out of scope for 
HTML 5 documents specification. I'm starting to think that at most it 
might be said, for disconnected subtrees outside any actual html 
document but consisting of html elements, that any API dealing with 
unique identifiers in a disconnected subtree of html elements must treat 
the value of any such element's id attribute as the element default ID 
(the id value uniqueness being a consequence of both its nature as ID 
property and the nature of an API methods targeting an element ID 
property, but not imposed by the specifications, since currently there 
is no such method in the scope of HTML 5 DOM). As a consequence, the id 
value uniqueness might be in scope for a DOM Core specification 
explicitly willing to handle ID properties in a disconnected (and 
'document-less') subtree of Elements, just because the id value 
represent (at least) the first attribute of an HTML element to be 
evaluated looking for an ID property.

Regard, 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:
 Check-up finanziario di Intesa Sanpaolo. Prenotalo subito online, è gratis e senza impegno.
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8437&d=7-12