- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 19 Jul 2014 08:55:19 -0400
- 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.
-Boris
Received on Saturday, 19 July 2014 12:55:50 UTC