- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 10 Sep 2010 18:35:04 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, "Jonas Sicking" <jonas@sicking.cc>
- Cc: "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, 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.) I agree that #3 is not really realistic. Ian mentioned it and I thought I should list it for completeness, but e.g. Live DOM Viewer relies on Node.attributes being on Element. (These are other potential optimizations we could consider. Moving interface members down from Node to to only where they are needed.) -- Anne van Kesteren http://annevankesteren.nl/
Received on Friday, 10 September 2010 16:35:54 UTC