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" <[EMAIL PROTECTED]>
To: "Jonas Sicking" <[EMAIL PROTECTED]>
Cc: "WHAT Working Group" <[email protected]>; "Simon Pieters"
<[EMAIL PROTECTED]>
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
