W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: [WebIDL] Remove ArrayClass?

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 19 Jul 2014 08:55:19 -0400
Message-ID: <53CA6AB7.5010104@mit.edu>
To: Dirk Schulze <dschulze@adobe.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
On 7/19/14, 7:55 AM, Dirk Schulze wrote:
> Removing ArrayClass will unlikely break content.

Sure.  I think we should aim slightly higher than not breaking content 
in API design.

>> And we've had repeated requests to do it for NodeList as well.  I plan to do it soon if I don't run into compat issues (which I don't expect to).
> It looks like WebKit has some experience with that already. The popular Closure library broke

Ah, that's useful information.  I read through your link, but there is 
nothing specific there about the failure other than that it involved 
concat.  What was the actual fail?  Was it code like this:

   var x = document.querySelectorAll("*");
   var y = x.concat();

or something else?

> HTMLCollections might have problems as well with ArrayClass[2].

HTMLCollections are not ok to ArrayClass, because they have a named 
getter.  No one is seriously proposing to use ArrayClass on them.

> It just seems like there is a lot of risk that we break content.

It would really help in cases like this if vendors running into these 
problems would report details to the relevant standards list so that we 
don't all just end up duplicating the same compat testing work.

> Maybe we can find alternative solutions like Array wrappers that must be called by authors explicitly: ArrayWrapper(getClientRects()).

Authors can already do Array.prototype.slice.call(getClientRects()) or 
Array.from(getClientRects()) in browsers that support enough ES6. 
Adding Array.from to the browsers that don't support it yet would help 
here more than anything else.

Received on Saturday, 19 July 2014 12:55:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC