This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Maybe also NodeIterator and AttrMap if we end up having to add that.
I also removed [ArrayClass] support per https://code.google.com/p/chromium/issues/detail?id=229398#c11 No longer worth persuing. I was unclear on NodeIterator. If anyone would like to have something there, let me know in a new bug. Thanks. https://github.com/whatwg/dom/commit/72a2f99e968571989790d58f5b35e8465c52a462
Why did you add legacyiterable to HTMLCollection? Especially without defining the actual resulting behavior? It's iterable anyway, because it has an indexed getter, and the resulting behavior seems just fine to me. Similar for NamedNodeMap, though there you spelled it wrong too. Adding iterable<> to DOMTokenList at least makes some sense if the goal is to get the extra methods... But the fact that it forces the use of a different iterator is pretty annoying. Cameron, could we have a way of getting the extra methods on something with an indexed getter without having to redefine the array iterator behavior?
As far as I can tell from IDL, if an interface has "supported property indices" you do not need to spell out the iterable behavior, but you do need the iterable<> declaration. Is that not true? It might be better if that were not true. (Having said that, that means I can remove the description from NodeList and DOMTokenList as well. I thought named getters were required for some reason.)
You have it backwards. Per http://heycam.github.io/webidl/#es-iterators you get an @@iterator if you have indexed props and a length, or an iterable declaration, maplike declaration, or setlike declaration. If you have an iterable declaration you then have to specify how it behaves. And the important part for purposes of this bug is this paragraph: If the interface does not have an iterable declaration but does define an indexed property getter, then the Function object is %ArrayProto_values% ([ECMA-262], section 6.1.7.4). I see that http://heycam.github.io/webidl/#idl-iterable has this language: Prose accompanying an interface with a value iterator MUST define what the list of values to iterate over is, unless the interface also supports indexed properties, in which case the values of the indexed properties are implicitly iterated over. which certainly makes it sound like in the indexed prop case iteration happens over those even in the face of an iterable declaration. This is flat-out contradicting the normative language in the es-iterators section, and I can only assume that this is a bug I didn't catch in reading over the text in bug 26183 because I only read the ES-relevant bits... I'll comment there.
Yeah, that language confused me. So I should remove the legacyiterable<> declaration from HTMLCollection and NamdeNodeMap and remove the description from NodeList and DOMTokenList. Correct?
The way things stand right now, if you have an iterable<> declaration you need a description of the iterator behavior. That is, explicitly saying you're iterable totally overrides the default behavior for indexed props. Obviously we can change Web IDL to not do that, but we should think about whether there are cases when someone _would_ want a non-default iterator behavior for something with indexed props.... You should definitely remove the legacyiterable bits, though. I see no use cases for that one, really.
I filed bug 26984 on removing legacyiterable from IDL. I filed bug 26985 on removing the requirement around prose for objects that have both indexed property getters and iterable<>. I filed bug 26986 on deprecating indexed property getters. For now in DOM I'll remove legacyiterable and leave the prose. Is there anything I'm still missing?
https://github.com/whatwg/dom/commit/f191218113035dbb023c697b6fc4cbc22c953284
Looks like I was moderately confused too. See bug 26985 comment 2. I think we still need Web IDL changes to improve the behavior to not make the use of iterable<> stop us using the array iterator, but the current spec does not in fact need prose for iterable<> on something with indexed props.
Thanks Boris. That was very helpful. https://github.com/whatwg/dom/commit/5e432dc0d618b717d711994f276bf523eb27f674