[whatwg] Early feedback on header association algorithm

Aaron Leventhal ha scritto:
> How about node.getElementByIdInSubtree?
>
> On 12/2/2008 4:07 PM, timeless wrote:
>> On Tue, Dec 2, 2008 at 10:39 AM, Aaron 
>> Leventhal<aaronlev at moonset.net>  wrote:
>>   
>>> Maybe there is a deeper problem if copy&  paste doesn't work right 
>>> because
>>> of IDs?
>>>
>>> Or maybe there should be a node.getDescendantById() method?
>>>      
>>
>> maybe, but not with that name.
>>
>>   Results 1 - 10 of about 4,480,000 for Descendent [definition]. 
>> (0.22 seconds)
>>   Results 1 - 10 of about 8,370,000 for Descendant [definition]. 
>> (0.41 seconds)
>>
>> the wikipedia links are confusing enough
>>
>> http://en.wikipedia.org/wiki/Descendant links to:
>> http://en.wiktionary.org/wiki/descendent
>> which has an also link to http://en.wiktionary.org/wiki/descendant
>> which has a 'US' audio file
>>
>> So the web says that '-dant' is favored 2:1 over '-dent', which is a
>> fairly bad margin considering the spelling errors we've seen in
>> html/http.
>>
>> I'd sooner see Node.getElementById and risk the confusion of it
>> returning fewer nodes than Document.getElementById.
>>
>>
>>    
>
>

That's about the same then moving the getElementById method from the 
Document interface to the Node interface
 (Document inherits from Node, so the actual traversed subtree would 
change basing on the node where the method is invocked, that is 
'anElement = document.getElementById("anEl")' would work as always, 
while anElement.getElementById("anEl") would look for a descendant of 
'anElement' with the same id), because, essentially, IDs are a common 
feature of all document types, despite the actual name of the attribute 
representing an ID, so an eventual .getElementByIdInSubtree() method 
should be defined on a somewhat DOM Core interface, and so would be out 
of scope for HTML 5 (as I've been told .getElementById is - there is a 
'Web DOM Core' specification under construction). But the term 'Subtree' 
arises a problem with HTML 5: actually, the id attribute is defined as 
the element unique ID in the *subtree* whithin which the element is 
found. That is, the term subtree refers to a whole document tree, but 
also to a disconnected subtree handled by a script (and I haven't yet 
understood if such definition refers to a document fragment containing 
nodes detached by any document, or a whole document without a browsing 
context).

Perhaps the possible confusion arising if moving .getElementById() to 
the Node interface might be avoided by leaving it on the document 
interface, and overloading it with, for instance,

Element   getElementById(in DOMString elementId, in Node rootElement);

so a call to document.getElementById would behave as always (or better, 
as it will be redefined in Web DOM Core, that should be 'pick the first 
element with a matching id'), and would coincide with a call to 
document.getElementById("something", document); while a call to 
document.getElementById("something", anElement) would search a matching 
ID among the descendants of 'anElement', whether anElement be a node of 
the current document, or a node removed by any document or created by a 
script, or a node in another document and both the current document and 
the current script context are enabled to access it (but a 'script 
context' is an HTML 5 related concept, so it might be generalized as a 
"DOM access context").

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:
 Personalizza il tuo cellulare con tantissimi temi!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8275&d=5-12

Received on Friday, 5 December 2008 10:19:04 UTC