W3C home > Mailing lists > Public > www-style@w3.org > May 2014

Re: [geometry] Add matrixTransform to DOMPoint

From: Dirk Schulze <dschulze@adobe.com>
Date: Fri, 23 May 2014 15:01:25 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: FX <public-fx@w3.org>, www-style <www-style@w3.org>
Message-ID: <3AD0E77E-131E-4E68-9FC7-30591DF1E040@adobe.com>

On May 23, 2014, at 4:24 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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?

Yes, it is not a live object and won’t be changed by the system after creation. It is a new created object.


> 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.

> ~TJ
Received on Friday, 23 May 2014 15:02:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:42 UTC