W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2010

[whatwg] Adding ECMAScript 5 array extras to HTMLCollection

From: J Z <kangax.dev@gmail.com>
Date: Sun, 25 Apr 2010 01:50:07 -0400
Message-ID: <s2j651a15de1004242250g4aa20877y93d38df993226681@mail.gmail.com>
On Fri, Apr 23, 2010 at 10:30 PM, David Bruant <bruant at enseirb-matmeca.fr>wrote:

> Hi,
>
> 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."
> This spec can be found here : http://www.w3.org/TR/DOM-Level-2-HTML/
>
> It defines ECMAScript language Binding (
> http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html). This
> document explains how to implement the DOM HTML interfaces in an
> ECMAScript-compliant environment.
>
> Because HTML5 is intended to replace DOM2 HTML, it can "freely" change
> ECMAScript bindings. My suggestion is the following :
> 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).
>
> 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.
> I don't think that the notion of "live object" and ECMAScript Array are
> incompatible either.
> Once again, I am talking about ECMAScript binding. I have no intention to
> touch the HTMLCollection interface or other languages bindings.
>
> Would the WHATWG have the power to decide something similar regarding
> NodeList ?
>
> Any thoughts ?
>
> Thanks,
>
> David
>

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):

for (var i = 0, length = collection.length; i < length; i++)
// instead of:
for (var i = 0; i < collection.length; i++)

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`):

HTMLCollection.prototype.__proto__ = Array.prototype;

document.getElementsByTagName('div').forEach(function(el) {
  el.parentNode.removeChild(el); // doesn't work as expected
});

// turning live collection into static array fixes this

Array.slice(document.getElementsByTagName('div')).forEach(function(el) {
  el.parentNode.removeChild(el);
});

-- 
kangax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100425/8bb8ebcf/attachment.htm>
Received on Saturday, 24 April 2010 22:50:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:22 UTC