W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [DOMCore] Attr

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 10 Sep 2010 09:46:27 -0700
Message-ID: <AANLkTinyKqer=bfR9=Avz9W=N-QKU5wH0mCTMhG7jtDE@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Ojan Vafai <ojan@chromium.org>, Maciej Stachowiak <mjs@apple.com>, Boris Zbarsky <bzbarsky@mit.edu>, "Olli@pettay.fi" <Olli@pettay.fi>, Adrian Bateman <adrianba@microsoft.com>, WebApps WG <public-webapps@w3.org>
On Fri, Sep 10, 2010 at 9:39 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Fri, Sep 10, 2010 at 9:35 AM, Anne van Kesteren <annevk@opera.com> wrote:
>> On Fri, 10 Sep 2010 18:28:14 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>>> Indeed, Node.attributes is currently the only way to enumerate all the
>>> attributes of an Element. This makes me think there are probably
>>> people out there doing this, and so I suspect Node.attributes is
>>> needed for web compat. Additionally, it seems bad to remove the
>>> ability to enumerate attributes completely. Lastly, keeping Attrs as a
>>> type of object gives us something to return from DOM-XPath.
>>> What I suggest is #2 in Anne's list. Make Attrs into objects with the
>>> following properties:
>>> * name
>>> * value
>>> * namespaceURI
>>> * localName
>>> 'name' would be my guess for most commonly used when iterating all the
>>> atttributes. The others are the minimum set of attributes needed for
>>> proper enumeration
>>> We might also consider these attributes, though if they're not needed
>>> for web compat, then it would be nice to not add them IMHO.
>>> * ownerElement
>>> * prefix
>>> * nodeName
>>> * nodeValue
>>> Also, I wouldn't mind making value/nodeValue readonly, but I don't
>>> feel strongly about that.
>> This in addition to #1 then, I assume? (Not having child nodes for Attr
>> would such a win already.)
> Yes, most definitely. The list of attributes above would be *all* the
> attributes on Attr objects, and .childNodes isn't in there.

Oh, another issue is what type the Node.attributes object should be.
It's currently a NamedNodeMap, but that won't work since those return
Nodes. We could either create AttrMap interface with the exact same
API, except that it returns Attrs instead of Nodes, or we can remove a
few of the functions.

I suggest we remove at least the mutating functions, leaving us with:

interface AttrMap {
  Attr               getNamedItem(in DOMString name);
  Attr               item(in unsigned long index);
  readonly attribute unsigned long   length;
  Attr               getNamedItemNS(in DOMString namespaceURI,
                                    in DOMString localName);

But I could even see removing the getNameItem/getNamedItemNS functions too.

/ Jonas
Received on Friday, 10 September 2010 16:47:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC