W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > June 2017

Re: [fxtf-drafts] [geometry] DOMMatrixReadOnly string init depends on backwards compatibility syntax

From: Joseph Orbegoso Pea via GitHub <sysbot+gh@w3.org>
Date: Thu, 15 Jun 2017 01:29:19 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-308602957-1497490157-sysbot+gh@w3.org>
> So after reading the old thread, the argument was not to be compatible with scripts using SVGMatrix, but being able to pass in transform attribute from SVG to new scripts using DOMMatrix.

You guys should all just forget about having this type of API. As @AmeliaBR pointed out [above](https://github.com/w3c/fxtf-drafts/issues/149#issuecomment-300622506), this type of API doesn't belong in DOMMatrix. Intead, specific APIs (like SVG or CSS) should have separate APIs for accepting and giving DOMMatrix instance.

For example, it could be like (just an example, may be completely off):

getComputedStyle(someElement).transform = new DOMMatrix([...]) // sets matrix() or matrix3d()

but you get the idea, those other places can house the specific APIs for dealing with DOMMatrices as needed.

There is CSS TypedOM coming soon hopefully, which can give us such APIs.

SVG can have it's own API (if it doesn't already, I'm don't know), and it can even work with the unitless no-comma format for generating DOMMatrix instances, or for getting instances, or whatever.

The following should simply not be allowed:

> ```js
> new DOMMatrix(svgElement.getAttribute('transform'));
> ```

> I am fine with using the CSS parser but we should definitely not use the strict mode!

Please no, let's have separation of the concerns. `DOMMatrix` is a mathematical number library, and if we allow people to create these things from strings, we're defeating the purpose. We need to speed up the web.

GitHub Notification of comment by trusktr
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/149#issuecomment-308602957 using your GitHub account
Received on Thursday, 15 June 2017 01:29:26 UTC

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