W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2014

Re: [geometry] Add matrixTransform to DOMPoint

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 23 May 2014 23:24:51 +0900
Message-ID: <CAAWBYDCLUX5TWZYYB7wYc-c0iB0c72rvWDzYmUHHQj2VTSetZA@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: FX <public-fx@w3.org>, www-style <www-style@w3.org>
On Thu, May 22, 2014 at 5:54 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> SVG has an interface SVGPoint which will be an alias for DOMPoint with Geometry Interfaces. However, SVGPoint has a method called matrixTransform [1]:
> interface SVGPoint {
>         ...
>         SVGPoint matrixTransform(SVGMatrix);
> }
> (SVGMatrix is an alias to DOMMatrix.)
> matrixTransform is not part of DOMPoint yet. I plan to add it to DOMPointReadOnly to be compatible with SVGPoint. The method is actually used by JS libraries such as d3.js which makes it (more or less) an integral part of the web platform. The function will look like:
> interface DOMPointReadOnly {
>         ….
>         DOMPoint matrixTransform(DOMMatrixReadOnly);
> }
> Please reply if you object to the change.
> Note: DOMMatrix has a similar functionality called transformPoint(DOMPointInit) which take a DOMPointInit dictionary such as {x: 0, y: 0, z: 0}. I believe that this is a valid functionality as well. We expect authors to use dictionaries more often in the future.

Did you intend for it to return a DOMPoint rather than a DOMPointReadonly?

Otherwise, looks fine to me.  Having a bit of redundancy with some
binary operations occurring on both argument interfaces is fine with
me; as long as they're consistent in behavior, it's often more
convenient for authors.

Received on Friday, 23 May 2014 14:25:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:49 UTC