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

Re: [WebIDL] Remove ArrayClass?

From: Dirk Schulze <dschulze@adobe.com>
Date: Sat, 19 Jul 2014 13:23:45 +0000
To: Boris Zbarsky <bzbarsky@mit.edu>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <4C4236DE-7DA0-421F-AA81-6CA2AF47B07F@adobe.com>

On Jul 19, 2014, at 2:55 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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?

I do not have more information than the bits that you filtered already. For current WebKit, you just need the part that does not patch V8 from https://bugs.webkit.org/attachment.cgi?id=170983&action=prettypatch. I suppose it is easier to add [ArrayClass] to NodeList.webidl in Gecko.

>> 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.

Ok. Thanks.

>> 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.

Maybe this is enough and just needs to be evangelist?


> -Boris
Received on Saturday, 19 July 2014 13:24:15 UTC

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