DOMRectList was set up as ArrayClass. The editor of WebIDL strongly suggested not to use the ArrayClass pattern. However, with the getter function DOMRectList behaves just like arrays.

Can't we change getClientRects() to just return an array?

(In reply to Anne from comment #2)
> Can't we change getClientRects() to just return an array?

Array's don't have item() for instance.

And people are using .item() rather than a getter?

Failing removal this API needs to be marked legacy in the specification. LegacyDOMRectList and [NoInterfaceObject] (the latter seems fine since you changed the interface name once already).

We should also add Symbol.iterator support to it.

And it probably needs to be more explicit about its associated list. Currently that is only apparent from the member definitions.

To clarify: DOMRectList is ancient. It used to be called ClientRectList and is a standardized version of API introduced in IE6 (or possibly earlier...).

Anything that preserves compat is fine by me, but we must preserve compat.

(In reply to Robert O'Callahan (Mozilla) from comment #5)
> To clarify: DOMRectList is ancient. It used to be called ClientRectList and
> is a standardized version of API introduced in IE6 (or possibly earlier...).
> 
> Anything that preserves compat is fine by me, but we must preserve compat.

An interface like:

[NoInterfaceObject,
ArrayClass]
interface DOMRectList {
   readonly attribute unsigned long length;
   getter DOMRect? item(unsigned long index);
};

Seems to get a broader acceptance so far.

(In reply to Dirk Schulze from comment #6)
> (In reply to Robert O'Callahan (Mozilla) from comment #5)
> > To clarify: DOMRectList is ancient. It used to be called ClientRectList and
> > is a standardized version of API introduced in IE6 (or possibly earlier...).
> > 
> > Anything that preserves compat is fine by me, but we must preserve compat.
> 
> An interface like:
> 
> [NoInterfaceObject,
> ArrayClass]
> interface DOMRectList {
>    readonly attribute unsigned long length;
>    getter DOMRect? item(unsigned long index);
> };
> 
> Seems to get a broader acceptance so far.

Anne, do you accept the compromise that implementers and the TAG agreed on? Can I close the bug report now?

Yeah I guess. Still seems odd to me we'd keep ArrayClass around for a handful of classes, but okay. 

What about iterator support? Is that a distinct bug?

(In reply to Anne from comment #8)
> Yeah I guess. Still seems odd to me we'd keep ArrayClass around for a
> handful of classes, but okay. 
> 
> What about iterator support? Is that a distinct bug?

Since the deprecated DOMRectList inherits from Array instead of Object, I would say that the same caution applies to DOMRectList as to Arrays. So be careful with for..in but you can use forEach() and you should still be able to define custom iterators.

If it inherits from Array it will inherit array's iterator support automatically.

(In reply to Domenic Denicola from comment #10)
> If it inherits from Array it will inherit array's iterator support
> automatically.

Of course.

Inherits from Array? That's not what [ArrayClass] means... What am I missing?

You are right, it does not mean precisely the right thing (e.g. class-side inheritance will be missing). But it does put Array.prototype in the prototype chain, which is enough to inherit the iteration behavior.

---

Separately: it sounds like foolip is willing to add a use counter for .item to Blink, which could allow us to remove DOMRectList in favor of Array if it is used very little.

(In reply to Domenic Denicola from comment #13)
> You are right, it does not mean precisely the right thing (e.g. class-side
> inheritance will be missing). But it does put Array.prototype in the
> prototype chain, which is enough to inherit the iteration behavior.

Anne, does this satisfy you request?

> 
> ---
> 
> Separately: it sounds like foolip is willing to add a use counter for .item
> to Blink, which could allow us to remove DOMRectList in favor of Array if it
> is used very little.

Since item() is the only way to get a ClientRect (aka DOMRect) from the list, we can already assume that the number will be height enough. I do not see any value in waiting for the use counter especially since it doesn't seem to be in Blink already.
I would be very much in favor for a Sequence, but it is very unlikely that we can get there right away.

(In reply to Dirk Schulze from comment #14)
> (In reply to Domenic Denicola from comment #13)
> > You are right, it does not mean precisely the right thing (e.g. class-side
> > inheritance will be missing). But it does put Array.prototype in the
> > prototype chain, which is enough to inherit the iteration behavior.
> 
> Anne, does this satisfy you request?
> 
> > 
> > ---
> > 
> > Separately: it sounds like foolip is willing to add a use counter for .item
> > to Blink, which could allow us to remove DOMRectList in favor of Array if it
> > is used very little.
> 
> Since item() is the only way to get a ClientRect (aka DOMRect) from the
> list, we can already assume that the number will be height enough. I do not
> see any value in waiting for the use counter especially since it doesn't
> seem to be in Blink already.
> I would be very much in favor for a Sequence, but it is very unlikely that
> we can get there right away.

Checked in WebKit again and getClientRects()[0] is possible. Even though it is not part of the IDL in WebKit. (Custom JS object.) So there are more ways then just item() to get a "ClientRect" in WebKit.

Having indexed getters is a direct result of having "getter" in the IDL.

To resolve this issue, I suggest going to CR with DOMRectList on the at-risk list. Should the getter indeed not be used, we could remove the interface from the spec during CR period. I added the following text to the spec:

""
The DOMRectList interface is at-risk. The authors of this specification await feedback from implementers if the getter of DOMRectList is currently in use on legacy interfaces. If there is no/not enough content to justify DOMRectList, legacy interfaces must use sequences instead and DOMRectList will be removed from this specification.
""

With the theoretical assumption that there is enough content that relies on the getter and we can not remove it, is the current spec'ed version acceptable for you Anne?

The getter is almost certainly in use. The question is whether the item() method is in use, no?

From the first 10 pages of https://github.com/search?l=javascript&q=getclientrects+item&type=Code&utf8=✓ I see 3 scripts using item():

https://github.com/danjo519/OnStage/blob/ac4e9c1aed05d702f4bbe6593133653695102b25/OnStage.Presentation.CompositionRoot/Scripts/shared/scriptViewer.js#L39
https://github.com/jdefez/Javascript-editor/blob/4763dfca84587690e95eb697f9a673aabcfe0175/class.editor.js#L127
https://github.com/Soren-Nordstrom/userscript/blob/26d0f409975460cd57fd9ec0f5e33118b95ef6fc/monolith/83/179754.user.js#L161

(In reply to Anne from comment #18)
> The getter is almost certainly in use. The question is whether the item()
> method is in use, no?

You are absolutely right and I'll clarify this. Do you agree that in case we can not get rid of item(), the current interface design addresses your issues?

(In reply to Simon Pieters from comment #19)
> From the first 10 pages of
> https://github.com/
> search?l=javascript&q=getclientrects+item&type=Code&utf8=✓ I see 3 scripts
> using item():

Most of the examples actually don't use item(). But I also think it is still used a lot. However, if browsers are willing to take the risk and get rid of them, why wouldn't we reflect that in the spec to match implementations? I think that is all I want to express with this at-risk item.

> 
> https://github.com/danjo519/OnStage/blob/
> ac4e9c1aed05d702f4bbe6593133653695102b25/OnStage.Presentation.
> CompositionRoot/Scripts/shared/scriptViewer.js#L39
> https://github.com/jdefez/Javascript-editor/blob/
> 4763dfca84587690e95eb697f9a673aabcfe0175/class.editor.js#L127
> https://github.com/Soren-Nordstrom/userscript/blob/
> 26d0f409975460cd57fd9ec0f5e33118b95ef6fc/monolith/83/179754.user.js#L161

See comment 8. TL;DR yeah, I guess.

(In reply to Dirk Schulze from comment #20)
> Most of the examples actually don't use item().

That doesn't really matter.

> But I also think it is still
> used a lot. However, if browsers are willing to take the risk and get rid of
> them, why wouldn't we reflect that in the spec to match implementations? I
> think that is all I want to express with this at-risk item.

Sure, I didn't try to argue one way or the other, just provide some data.

Use counter for ClientRectListItem
https://www.chromestatus.com/metrics/feature/timeline/popularity/694
reportedly in M43, you won't see that reach stable until June.

I think any change here should be together with MediaList and StyleSheetList since they also use [ArrayClass]

http://dev.w3.org/csswg/cssom/#medialist
http://dev.w3.org/csswg/cssom/#stylesheetlist

Github search for "document stylesheets item" gives 0 relevant matches
https://github.com/search?utf8=✓&q="document+stylesheets+item"&type=Code&ref=searchresults

(even "stylesheets item" gives 0 relevant matches
https://github.com/search?l=javascript&q="stylesheets+item"&ref=searchresults&type=Code&utf8=✓
)

Github search for "cssrules" "media item" gives non-zero relevant matches
https://github.com/search?l=javascript&q="cssrules"+"media+item"&ref=searchresults&type=Code&utf8=✓

(In reply to Simon Pieters from comment #23)
> I think any change here should be together with MediaList and StyleSheetList
> since they also use [ArrayClass]

philipj points out that MediaList has appendMedium() and deleteMedium() so that can't be replaced with an array.

What was the rationale for [NoInterfaceObject]? It's not clear to me from the comments what the benefit is.

(In reply to Simon Pieters from comment #23)
> Use counter for ClientRectListItem
> https://www.chromestatus.com/metrics/feature/timeline/popularity/694
> reportedly in M43, you won't see that reach stable until June.

M43 reached stable on May 19, and usage of ClientRectList is very, very low.

Yay, let's kill it! Normal arrays for everyone!!

(In reply to Philip Jägenstedt from comment #26)
> (In reply to Simon Pieters from comment #23)
> > Use counter for ClientRectListItem
> > https://www.chromestatus.com/metrics/feature/timeline/popularity/694
> > reportedly in M43, you won't see that reach stable until June.
> 
> M43 reached stable on May 19, and usage of ClientRectList is very, very low.

Oops, I mean ClientRectList.item(), but then that is the only compat concern here apart from various (less probably) ways of depending on window.ClientRectList.

Asked blink-dev about killing DOMRectList and there were no replies:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/qQCeHdAbGz0/DLdmT45mpY4J

In other words, please go ahead and change DOMRectList to sequence<DOMRect> in the spec. I don't think this needs to be blocked on figuring out the fate of other *List interfaces in CSSOM.

(In reply to Robert O'Callahan (Mozilla) from comment #5)
> To clarify: DOMRectList is ancient. It used to be called ClientRectList and
> is a standardized version of API introduced in IE6 (or possibly earlier...).
> 
> Anything that preserves compat is fine by me, but we must preserve compat.

roc, are you OK with switching to sequence<DOMRect> given the very low use of item() per usecounter data?

Yes

https://github.com/w3c/fxtf-drafts/commit/5ab338eef4ea4529b516d8f694a903ddea64e05a
https://github.com/w3c/csswg-drafts/commit/ebc0d23a692d703ef48dd634b01db9be433ca6c6

It looks like absolutely no browsers have made this change in the nearly two years since the spec was changed.  I checked in Firefox, Chrome, Safari, Edge.

The use counter data at https://www.chromestatus.com/metrics/feature/timeline/popularity/694 still looks pretty low, so maybe this is still an OK change to make...

Did bugs get filed on implementations here?  Are there reasons why the change hasn't happened, other than everyone not making it a priority?

I had not filed bugs for this. :-(

It was however implemented in WebKit and it has now broken Google spreadsheet:

https://bugs.webkit.org/show_bug.cgi?id=172703

Philip, is https://www.chromestatus.com/metrics/feature/timeline/popularity/694 accurate? Should we try to get Google spreadsheet fixed and hope nothing else regresses, or revert the change?

https://github.com/w3c/csswg-drafts/issues/1479