[whatwg] Adding ECMAScript 5 array extras to HTMLCollection
dhtmlkitchen at gmail.com
Mon Aug 2 12:25:57 PDT 2010
On 8/2/10, Oliver Hunt <oliver at apple.com> wrote:
> On Aug 2, 2010, at 7:36 AM, And Clover wrote:
>> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>>> all array functions defined in ES5 are "generic" in that they work
>>> over any array-like object.
>> They're *not* guaranteed to work on host objects like the various node
> Uhhh, I have no idea what you're talking about -- there are no type checks
> in any of the array prototype functions, they all operate in terms of
> property access alone, all the methods we're talking about basically start
> out like this:
And they continue like this:
"Whether the [something] function can be applied successfully to a
host object is implementation-dependent."
Where "[something]" is replaced by "slice" in this case.
> Eg. "array-like" in the context of ES5 should be interpreted as "has a
> property named 'length', the array methods will work on any type.
That is not true. ECMAScript has what is called "host object". A host
is any ecmascript object that is not defined by the specification; it
is not a user-defined object (because that explicitly defined to be a
A host object may or may not be implemented as a native ECMAScript
object. That leaves two types of host objects:
More on that:
Nothing says that any of the various dom "collection" objects must be
The W3C does not define an interface "collection"; The term itself
comes from Microsoft IE 4, which predates the w3c DOM; hence the
quotes around the term "collection".
>> FWIW in practice `Array.prototype.*.call(htmlcollection)` does work on the
>> modern desktop browsers except for IE.
>> It would be possible to specify that the native-JS object guarantee should
>> also extend to node lists. This would allow fast browser implementations
>> of the array-like methods to be used without having to copy to a new
>> Array. However this would still leave the method of calling them a little
> As above there is no question of it being possible -- the spec behaviour
> makes no exceptions for host vs. native object types. If IE has a bug, then
> IE has a bug, that doesn't change the spec.
IE does not have a bug. IE does not implement its host objects as
native ES objects. I proposed to change that by defining an interface
that would require that, as well as putting a definition of [[Get]]
property access on such objects in one place; not scattered through
various interfaces as they currently are and will continue to be
otherwise, with the proliferation of new indexed "collection" type
More information about the whatwg