- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Tue, 19 Oct 2010 09:50:35 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Erik Arvidsson <arv@chromium.org>, Cameron McCormack <cam@mcc.id.au>, public-webapps@w3.org
On 10/19/10, Anne van Kesteren <annevk@opera.com> wrote: > On Tue, 19 Oct 2010 03:11:25 +0200, Cameron McCormack <cam@mcc.id.au> > wrote: >> Does it particularly matter that collection.item(999) returns null while >> collection['999'] evaluates to undefined? To me, it makes sense enough. >> Functions and properties that returns Nodes, and which have no Node to >> return, return null. I think for consistency with all of these other >> funtions and properties, it is preferable to return null from >> collection.item(). That’s a much bigger (better) consistency to strive >> for than one between collection.item(999) and collection['999'], IMO. > > It is certainly my goal to make CSSOM (and anything else I edit) > consistent with this if that was the (indirect) question (not sure why > else I would be on the cc list). I just have not familiarized myself yet > with the particulars of Web IDL in this area (and have not been working on > CSSOM for a while). > > Erik linked to two collection types, HTMLCollection (and I see js error "fixBrokenLink is not defined" again) and also CSSStyleDeclaration. What about the other "collection" objects? HTML5 says that collections are now callable and specifies that "indexed" property access on collections returns null. But what about other APIs such as NodeList, NamedNodeMap, CSSRuleList, and StyleSheetList? Changing the wording for each collection would be painfully repetitious, involving a spec author for each spec. There is not any super interface collection defined that also defines `item`, callability, property access, etc. though if there were then all collection type objects inherit from that and would avoid shotgun surgery. That would seem to be something for DOM 4 core, if such a thing is to be written. Garrett
Received on Tuesday, 19 October 2010 16:51:30 UTC