On Fri, Apr 23, 2010 at 10:30 PM, David Bruant <span dir="ltr"><<a href="mailto:bruant@enseirb-matmeca.fr">bruant@enseirb-matmeca.fr</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
In the HTML5 "status of this document" section, one can read : "This specification is intended to replace (be the new version of) what was previously the [...] DOM2 HTML specifications."<br>
This spec can be found here : <a href="http://www.w3.org/TR/DOM-Level-2-HTML/" target="_blank">http://www.w3.org/TR/DOM-Level-2-HTML/</a><br>
<br>
It defines ECMAScript language Binding (<a href="http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html" target="_blank">http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html</a>). This document explains how to implement the DOM HTML interfaces in an ECMAScript-compliant environment.<br>
<br>
Because HTML5 is intended to replace DOM2 HTML, it can "freely" change ECMAScript bindings. My suggestion is the following :<br>
Make that HTMLCollection (and all HTML*Collection, as a consequence of inheritence of HTMLCollection) inherit from the ECMAScript Array prototype. This way, it will make available all Array extra methods (forEach, map, filter...) added in ECMAScript5 (and next versions which should go in the same direction).<br>
<br>
As far as I know, adding this won't break any existing code. The semantics of a Collection and the way it is used is very close from ECMAScript Arrays.<br>
I don't think that the notion of "live object" and ECMAScript Array are incompatible either.<br>
Once again, I am talking about ECMAScript binding. I have no intention to touch the HTMLCollection interface or other languages bindings.<br>
<br>
Would the WHATWG have the power to decide something similar regarding NodeList ?<br>
<br>
Any thoughts ?<br>
<br>
Thanks,<br><font color="#888888">
<br>
David<br>
</font></blockquote></div><br>As far as I can see, liveness of HTMLCollection actually does matter. When iterating over HTMLCollection, it's more or less a rule of thumb to "save" length, to avoid any kind of mismatch (in case code within loop modifies document and so affects length of collection in question):<br>
<br>for (var i = 0, length = collection.length; i < length; i++)<br>// instead of:<br>for (var i = 0; i < collection.length; i++)<br><br>If HTMLCollection was inheriting from Array, and methods like `forEach`, `map`, etc. were to operate on a live object, there would definitely be undesired consequences. We can see this in, say, Firefox (which allows to set [[Prototype]] of `HTMLCollection` to `Array.prototype`):<br>
<br>HTMLCollection.prototype.__proto__ = Array.prototype;<br><br>document.getElementsByTagName('div').forEach(function(el) {<br> el.parentNode.removeChild(el); // doesn't work as expected<br>});<br><br>// turning live collection into static array fixes this<br>
<br>Array.slice(document.getElementsByTagName('div')).forEach(function(el) {<br> el.parentNode.removeChild(el);<br>});<br><br>-- <br>kangax<br>