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

RE: [geometry] DOMRectList with legacy

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Thu, 17 Jul 2014 13:12:44 +0000
To: Dirk Schulze <dschulze@adobe.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, FX <public-fx@w3.org>
Message-ID: <ad307bff925643dd8d92f882178b2f10@BN1PR05MB325.namprd05.prod.outlook.com>
So, when I first wrote about DOMRectList, I did not realize it was a legacy artifact; I thought this spec was building new classes from scratch. That shifts things more toward "do the minimum necessary" and away from "what's the best design here?" This is especially the case since getBoxQuads() replaces getClientRects() and so in theory users shouldn't ever have to see this class in new code.

As such, the minimum IMO would be:

- Make it [NoInterfaceObject]
- Rename it LegacyDOMRectList (or better, LegacyGetClientRectsReturnValueType :P)

to avoid it leaking into user code and into other specs.

The best design IMO would be to simply return a normal array. This would be backward-incompatible due to removing .item() and so would require usecounters/telemetry, etc. Given that users are supposed to use getBoxQuads() instead, this seems like too much work for something that's not a guaranteed payoff.

There are intermediate steps that could be done to improve the user experience for getClientRects() without the cost of backward-incompatibility. The second-best design would be a true Array subclass, but since no browsers support that yet (and plans for doing so are still unclear), [ArrayClass] gives most of the benefits. Boris did a good job summarizing those---in general, authors *hate* having to do Array.prototype.slice.call(...) to get something with the normal Array methods. It is one of the top DOM WTFs these days.

For the record, here are the things I can think of that [ArrayClass] fails to give versus a real subclass:
- Static methods like LegacyDOMRectList.from and LegacyDOMRectList.of
- Fixes the return types of the various methods (concat, map, filter, etc.) to return LegacyDOMRectList instead of Array.
- Easily able to add a constructor that behaves like Array's (just call super)

-----Original Message-----
From: Dirk Schulze [mailto:dschulze@adobe.com] 
Sent: Thursday, July 17, 2014 02:08
To: public-script-coord@w3.org; FX
Subject: [geometry] DOMRectList with legacy

Hi,

Geometry Interfaces describes an interface for a list of DOMRects called DOMRectList[1]. DOMRectList is legacy and implemented as ClientRectList in some browsers (without constructor).

One reviewer feedback was that it should be more Array like[2]. So there are two possibilities 
1) Make it a subclass of Array
2) Make it an [ArrayClass]

Another proposal was making DOMRectList an [NoInterfaceObject][3].

Furthermore, it was suggested[3] not to use this kind of interface in other places and clearly mark it as legacy.

s/DOMRectList/LegacyDOMRectList/

I go with [ArrayClass] and will add the change to the spec soon. We can rename it to LegacyDOMRectList. A note about it's legacy state should definitely be added though.

Greetings,
Dirk

[1] http://dev.w3.org/fxtf/geometry/#DOMRectList
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26200#c0
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26200#c4
Received on Thursday, 17 July 2014 13:13:20 UTC

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