[bindings] Support ArrayClass WebIDL attribute

[bindings] Support ArrayClass WebIDL attribute

This feature is no longer used for NodeList or HTMLCollection, however
CSSOM and Geometry find uses for it.

BUG=229398
LOG=N
R=arv@chromium.org, haraken@chromium.org

[caitp (gmail), 2015-06-30 23:05:12]

Hi, PTAL some time if interested!

Unfortunately, this doesn't seem to be needed for DOM anymore, but several W3C
drafts are still wanting to use it, so I thought I'd see if anyone thought it
was worth having.

[haraken, 2015-06-30 23:52:12]

Given that there is no use case or no planned use case, I'd say it's not worth
supporting. It will just add an unnecessary maintenance cost to the code base.

[caitp (gmail), 2015-07-01 00:18:11]

On 2015/06/30 23:52:12, haraken wrote:
> Given that there is no use case or no planned use case, I'd say it's not worth
> supporting. It will just add an unnecessary maintenance cost to the code base.

The bigger one is iterable declarations, but since this is spec'd for MediaList
and other interfaces, I wanted to see if anyone working on those would want it.
I saw eseidel in the blame for MediaList so I was hoping he'd chime in on
whether it's worth the extra 20 lines

[haraken, 2015-07-01 00:21:23]

On 2015/07/01 00:18:11, caitp wrote:
> On 2015/06/30 23:52:12, haraken wrote:
> > Given that there is no use case or no planned use case, I'd say it's not
worth
> > supporting. It will just add an unnecessary maintenance cost to the code
base.
> 
> The bigger one is iterable declarations, but since this is spec'd for
MediaList
> and other interfaces, I wanted to see if anyone working on those would want
it.
> I saw eseidel in the blame for MediaList so I was hoping he'd chime in on
> whether it's worth the extra 20 lines

eseidel is not working on Blink...

[caitp (gmail), 2015-07-01 00:24:40]

On 2015/07/01 00:21:23, haraken wrote:
> On 2015/07/01 00:18:11, caitp wrote:
> > On 2015/06/30 23:52:12, haraken wrote:
> > > Given that there is no use case or no planned use case, I'd say it's not
> worth
> > > supporting. It will just add an unnecessary maintenance cost to the code
> base.
> > 
> > The bigger one is iterable declarations, but since this is spec'd for
> MediaList
> > and other interfaces, I wanted to see if anyone working on those would want
> it.
> > I saw eseidel in the blame for MediaList so I was hoping he'd chime in on
> > whether it's worth the extra 20 lines
> 
> eseidel is not working on Blink...

He's in the blame and has shown up on the mailing list a fair bit. Open to
suggestions on other people to all who are or have been working on features
which would use this

[caitp (gmail), 2015-07-01 11:45:53]

caitpotter88@gmail.com changed reviewers:
- eseidel@chromium.org

[caitp (gmail), 2015-07-01 14:32:11]

caitpotter88@gmail.com changed reviewers:
+ jsbell@chromium.org

[jsbell, 2015-07-01 17:51:09]

This thread makes me nervous:

https://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0077.html

Specifically, breaking Closure. i.e. we should track down what happened and make
sure we've got tests that cover that (regardless of what we do here)

It's a year ago so we may have more data. In particular, we should see if Moz is
planning to keep this or remove it; there were webidl bugs (can't find them
now...) talking about removing [ArrayClass].

At the very least we should follow up with boris zbarsky and find out the latest
thinking.

[arv (Not doing code reviews), 2015-07-01 18:02:42]

On 2015/07/01 17:51:09, jsbell wrote:
> Specifically, breaking Closure. i.e. we should track down what happened and
make
> sure we've got tests that cover that (regardless of what we do here)

FWIW, @@isConcatSpreadable would have saved Closure.

[caitp (gmail), 2015-07-16 14:06:31]

Cameron's spec renamed this to [LegacyArrayClass], so maybe it's been given up
on entirely in favour of Elements and iterable<>. Gonna close this one until
someone wants api compat with gecko for MediaList or DOMRectList