[whatwg] Use cases for Node.getElementById

There are lots of times in which I've needed to examine one document by use 
of a script that resides inside another. Using lists of attributes to do 
that has been rather important, though if those lists were accessible as 
properties of objects rather than as nodes themselves (as in some sort of 
multinary relation rather than as a tree structure) that would be fine as 
well. Learners of this stuff seem to have trouble with the fact that lists 
cannot be indexed through array notation -- i.e., that nodes[1] cannot be 
used in place of nodes.item(i) in some namespaces, but apparently can in 
HTML.

Though I have only played a little with compound documents or with document 
fragments, it seems like viewing all nodes as accessible through 
getElementById is awfully dependent on how one finds the "document" 
associated with the appropriate segment of a mixed NS document. In SVG 
nestled inside HTML, for example, implementations have differed in terms of 
how that document is retrieved as a function of browser, and the type of tag 
(object, iframe, frame, or embed) in which the svg is placed. The ability to 
"root" one's search directly at a certain level in the parent DOM, might 
help in cases where mixed name spaces could lead to conflicts of the 
assumption of unique id's.

Perhaps this has been addressed already, since I'm pretty sure the folks 
involved in this conversation know more about what they are talking about 
than I do.

cheers
David

----- Original Message ----- 
From: "Calogero Alex Baldacchino" <alex.baldacchino@email.it>
To: "Jonas Sicking" <jonas at sicking.cc>
Cc: "WHAT Working Group" <whatwg at lists.whatwg.org>; "Simon Pieters" 
<simonp at opera.com>
Sent: Monday, December 08, 2008 6:47 PM
Subject: Re: [whatwg] Use cases for Node.getElementById


> Jonas Sicking ha scritto:
>>>> I see the Element interface no more contains methods to handle Attr 
>>>> nodes: since those are described as not being child nodes of an 
>>>> Element, in W3C specifications, there will be any other way to handle 
>>>> attributes as nodes, the 'nature' of Attr nodes is going to change, or 
>>>> is there a too little use (and/or support) of them, such that the Attr 
>>>> interface might be quite close to its 'end of life'?
>>>
>>> I'm not sure what to do with attributes. I'd like to drop support for 
>>> attribute nodes (being moved around, etc), if possible, but keep the 
>>> .attributes list and be able to use .value etc on each attribute.
>>
>> Oooh, this is an interesting idea. It'd be great if we could make 
>> attributes not be nodes but rather some other type of object.
>>
>> Ideally I'd like for them to not exist at all, and have people just use 
>> getAttribute(NS) instead. I've never thought that their usefulness 
>> outweighed their complexity.
>>
>> / Jonas
>
> Effectively, Attrs are nodes, but aren't used as 'normal' nodes; that's 
> complex. Perhaps they might have been defined as not inheriting from Node 
> since their introduction. If creating two new interfaces, one replacing 
> Attrs (perhaps called Attr as well, but not inheriting from Node), the 
> other to list attributes (AttributeCollection?), doesn't rise any issue on 
> backward compatibility, or it solves more problems than it may create, 
> that's not a bad idea. :-)
>
> For sure, getting/setting an attribute as a property of an element, 
> through getter/setter methods taking and returning strings is easier and 
> perhaps the best choice in most cases, but there might be use cases where 
> the possibility to access an element's attributes as a list is worth it, 
> so, perhaps, should the drop of Attr be filed for a deep analysis and a 
> possible actuation in a successive version of Web DOM Core (maybe 
> modifying the Attr interface in the current)?
>
>
> --
> 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:
> Gioca e vinci con Sheba! * Partecipa a concorso "I sensi di un'intesa 
> perfetta" vinci fantastici premi per il tuo gatto! * Clicca qui: 
> http://adv.email.it/cgi-bin/foclick.cgi?mid=8433&d=9-12
>
>

Received on Monday, 8 December 2008 18:38:44 UTC