[whatwg] Use cases for Node.getElementById

[Calogero Alex Baldacchino]

ddailey ha scritto:
> 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.

Well, attributes shouldn't be accessible as descendants of an Element in 
a tree structure, but rather as items of a NamedNodeMap, or directly 
through Element.getAttribute()/Element.getAttributeNS(), passing a 
string representing the attribute name and getting the value as a 
string. Thus, they don't need to be instances of Node (that's about 
redefining Attr and a related listing interface to simplify the UA 
handling of attributes, which currently are node but should be handled 
as if they weren't). Any interface replacing Attr, for such purpose, 
should take care of namespaces and prefixes (which is currently done in 
DOM3 Node interface). Dropping the list of attributes as objects would 
require to query each attribute by name, but a list of attributes seems 
to be needed in some use cases; a DOMStringMap might be considered, to 
represent attributes as a list of string couples of names and values, 
but such couldn't handle namespaces, though it might be derived to add 
such capability, nor it could solve the problem to define an interface 
to give access to a tuple of (name, value, namespace) by colling, e.g., 
an item() method, or the alike. Otherwise, if no better alternative can 
be found, Attrs will continue to be Nodes...

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

I guess that's a matter of idl bindings, in part at least, so it might 
be solved with clearer specific bindings, as needed. For instance, all 
properties (attributes and methods) of a collection-like interface can 
be declared [DontEnum], despite of them being defined on the idl or 
being created at runtime (i.e. by listing an item as a named property of 
the object), with the exception of indexed items: this way, a 
collection-like object would always behave as an Array-like object. 
Similarly, the collection might work as an associative array for named 
items (i.e., the_id = attributes["id"] might work as the_id = 
attributes.getNamedItem("id") ), but the binding for such might be more 
complex, involving a redefinition of the bracket property accessor in 
order to look for properties inside an internal list (when it comes to 
implementations, such complexity may disappear or be reduced, for 
instance, in C++ such might involve an "easy" overload of the 
'operator[]' function).

> 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, what you're asking for is something like 
Document.getNSElementById(in DOMString namespaceUri, in DOMString 
elementId), to get access to the first element, in a document, whose tag 
name has a prefix corresponding to the queried namespace, or is 
descendant of an element whose tagname is the root element tag name for 
the queried namespace (perhapse suitable for HTML 5 embedding <svg> or 
<math> elements without prefixes). Anyway, you'd have to reach the 
correct document first (but you'd have to do so to get the nested 
content root element even with a getElementById(elementId, rootElement) 
). Such method would involve a separate management of ids, one to ensure 
uniqueness in the whole document (i.e. to return the first match for 
getElementById despite of the element namespace), another to deal with 
each element (either prefixed or just embedded) coming from the same 
namespace as if they were in a separate document where to look for 
unique ids (not to be implemented necessarily this way, just managing a 
global map of unique IDs for all the elements in a document and zero or 
more secondary maps for all the elements corresponding to a particular 
namespace - different from that of the nesting document). Such might add 
some complexity to the user agent, and perhaps won't get consensus from 
implementors, I guess.

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:
 Dalla top ten al tuo cellulare. Scarica le superhit!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8268&d=9-12