Can WebKitCSSMatrix be an alias of DOMMatrix?

[foolip]

@miketaylr, can you help me figure out what's blocking making WebKitCSSMatrix an alias of DOMMatrix, so that window.WebKitCSSMatrix and window.DOMMatrix are the same constructor?

Looking at the current spec, it seems like the only things are Constructor(DOMString transformList) and Constructor(WebKitCSSMatrix other), the other overrides are just making sure that the returned object is a WebKitCSSMatrix.

If there is nothing else, maybe we can have those constructors added to https://drafts.fxtf.org/geometry/#dommatrix ?

[miketaylr]

This is something I had originally hoped was possible. Here are the 2 main differences, other than constructors you mention:

1. DOMMatrix.scale(scale, scaleX, scaleY) and WebKitCSSMatrix.scale(scaleX, scaleY, scaleZ) have different method signatures.

(Maybe it's better to define WebKitCSSMatrix.scale() as DOMMatrix.scale3d(1, scaleX, scaleY, scaleZ)? Right now it's defined in terms of DOMMatrix.scaleNonUniform().)

1. DOMMatrix.rotate(angle, originX, originY) and WebKitCSSMatrix.rotate(rotX, rotY, rotZ) have different method signatures. I'm not sure if it's possible to implement WebKitCSSMatrix.rotate in terms of DOMMatrix.rotate or DOMMatrix.rotateAxisAngle. Maybe @zcorpan has an idea.

[foolip]

I see that Firefox has shipped DOMMatrix already, but not Chrome, Edge or Safari. What do you think about simply changing DOMMatrix to match WebKitCSSMatrix? Since only Gecko has DOMMatrix so far, I don't suppose too much could depend on it, right?

[zcorpan]

@rocallahan

[rocallahan]

I don't really know, but I assume we can change it.

[foolip]

@zcorpan @dirkschulze @cabanier, you're the editors of https://drafts.fxtf.org/geometry/Overview.html#DOMMatrix

Do you see a problem with making scale and rotate behave like WebKitCSSMatrix, and perhaps adding separate methods if the existing semantics are better for some use cases?

[zcorpan]

There is also SVGMatrix which DOMMatrix is supposed to supersede and be compatible with, and SVGMatrix is widely supported. I don't know which of SVGMatrix and WebKitCSSMatrix are more widely used, but I suppose it is not possible to be compatible with both...

[zcorpan]

Can't WebKitCSSMatrix inherit from DOMMatrix, and shadow scale and rotate? WebKitCSSMatrix can only be constructed, it's not returned from some other API?

[foolip]

A quick glance at Blink's IDL for SVGMatrix and WebKitCSSMatrix suggests that they could be merged. SVGMatrix has a few methods with the same names but fewer arguments, and a few extra methods, but I see no obvious conflicts in semantics.

There is the trouble that SVGMatrix is a tear-off, but that seems to equally problematic if trying to merge it into DOMMatrix.

[foolip]

As for inheriting and shadowing, that is what the spec currently does, but then you have to shadow everything so that it returns a WebKitCSSMatrix instead of a DOMMatrix. Just making all of the matrix types aliases ought to simplify things, if it actually works out.

[zcorpan]

OK, yeah. Sorry for not paying proper attention; I should be sleeping. :-)

I thought WebKitCSSMatrix#rotate with one argument would only scale X, but I see now it scales both X and Y in that case.

If they are indeed compatible then I don't mind changing DOMMatrix.

[foolip]

I think the most consequential differences between DOMMatrix and WebKitCSSMatrix are the ones pointed out in #19 (comment)

There's also the fact that multiply should take another object, a setMatrixValue method and perhaps other minor things. Happy to go through it it in detail if you agree that merging seems worthwhile.

[zcorpan]

multiply and setMatrixValue look like they are compatible, though?

[zcorpan]

From a quick github search it looks like most invocations of the constructor either use no argument or a string -- not another WebKitCSSMatrix instance.

[foolip]

It's WebKitCSSMatrix multiply(WebKitCSSMatrix other) vs. DOMMatrix multiply(optional DOMMatrixInit other). So it's the optional keyword. I guess that DOMMatrix looks like a DOMMatrixInit dictionary and that's why it works?

When I commented I think setMatrixValue was only in one of the specs, or perhaps I just failed to find it in one of them. They indeed look compatible.

[zcorpan]

Yep. Moving from required to optional shouldn't be a problem for Web compat.

The other thing is whether we should drop some other methods in the Geometry spec, like scaleNonUniform (which is like webkit-scale).

[foolip]

Yeah, dropping anything that becomes redundant sounds like a good idea, assuming it's not shipped and used by web content.

[zcorpan]

OK so I've made a series of changes to Geometry to address this. Commits:

w3c/fxtf-drafts@430bc88
w3c/fxtf-drafts@99e3212
w3c/fxtf-drafts@8493a9c
w3c/fxtf-drafts@3c43462
w3c/fxtf-drafts@feba855
w3c/fxtf-drafts@a9fe6a7

Pls review :-)

[miketaylr]

Thanks @zcorpan -- I had a quick glance but will take a closer look on Monday (flying home in a few hours). I assume we still want to do #34 (comment)?

[zcorpan]

Yeah, IMO at least

[foolip]

Anything I need to look at? Next step is to actually make WebKitCSSMatrix an alias of DOMMatrix?

[miketaylr]

w3c/fxtf-drafts@3c43462

I also don't know about any content that relies on new WebKitCSSMatrix(other)... the only thing I've been able to find (on github and in my small web-JS corpus) is https://github.com/WebKit/webkit/blob/67985c34ffc405f69995e8a35f9c38618625c403/LayoutTests/platform/ios-simulator/ios/css/resources/construct-WebKitCSSMatrix.js, which references rdar://problem/6481690.

[zcorpan]

OK looked in httparchive now as well:

SELECT COUNT(*) AS num, REGEXP_EXTRACT(body, r'(new\s+WebKitCSSMatrix\s*\(\s*[^\(\)]+(?:\([^\)]*\)[^\)]*)?\))') AS match
FROM [httparchive:runs.2014_08_15_requests_body]
GROUP BY match
ORDER BY num DESC

results-20160127-070311.csv.zip

All of these pass in webkitTransform computed style, or a variable that needs further inspection to see what it is.

SELECT page, url, REGEXP_EXTRACT(body, r'(new\s+WebKitCSSMatrix\s*\([a-zA-Z]+\))') AS match
FROM [httparchive:runs.2014_08_15_requests_body]
WHERE REGEXP_MATCH(body, r'(new\s+WebKitCSSMatrix\s*\([a-zA-Z]+\))')

22 rows, all inspected manually; those that weren't 404 now were passing in webkitTransform computed style.

So no instances that pass in another WebKitCSSMatrix AFAICT.

[foolip]

FWIW, Blink doesn't have a WebKitCSSMatrix constructor that takes another WebKitCSSMatrix, just Constructor(optional DOMString cssValue). Why does the spec have one?

[zcorpan]

cc @grorg

[miketaylr]

Why does the spec have one?

That's... a good question. I can't recall why I added it, now that I'm looking over WebKit's implementation. So probably just a mistake that can be removed.

[miketaylr]

How does the following end up working (in Chrome)?

m = new WebKitCSSMatrix();
m2 = m.rotate(10, 20, 30);
m3 = new WebKitCSSMatrix(m2)
m3.a == m2.a.toPrecision(6)

(this might be some WebIDL magic I don't know about)

[zcorpan]

It toStrings to a <transform-list>

[zcorpan]

In Geometry the WebIDL magic is stringifier + prose

[miketaylr]

Ah, there we go. So yes, that constructor is just a spec (editor) bug.

[miketaylr]

@zcorpan here is some more feedback from wchen:

https://bugzilla.mozilla.org/show_bug.cgi?id=1241575#c6

Some quirks I noticed while working on this (and may need to be spec'ed):
- Chrome will accept "none", "inherit" and "initial". Safari will only accept "none". This patch will only accept "none" and treat it as the a 2d identity matrix (Chrome and Safari don't keep track of the is2D flag).
- Chrome and Safari will accept an empty string as a transform list but will syntax error on a string consisting of only whitespace. Empty string is treated as the identity matrix. This patch does the same.
- Chrome accepts relative length values. Safari accepts only absolute length values. DOMMatrix spec says to syntax error if values are not absolute length. This patch only accepts absolute length values.
- Calculated values are accepted in Chrome and accepted (but buggy and crashy) in Safari. This patch treats calculated values as a syntax error.

As for the "parse transform lists as a transform property" problem (issue #34), what do you think makes more sense -- leaving the DOMMatrix spec as-is or speccing the WebKitCSSMatrix alias to only take transform property syntax? (Seems kinda weird to have aliases with different behavior...).

Or possibly a note that for historical reasons the WebKitCSSMatrix constructor is allowed to only use transform property syntax.

[miketaylr]

And then in theory we can just delete this whole thing from the compat spec, once the small issues are worked out?

(and file bugs for Gecko to update its DOMMatrix/DOMMatrixReadOnly implementation).

[zcorpan]

As for the "parse transform lists as a transform property" problem (issue #34), what do you think makes more sense -- leaving the DOMMatrix spec as-is

Yes. See #34 (comment)

Or possibly a note that for historical reasons the WebKitCSSMatrix constructor is allowed to only use transform property syntax.

That doesn't make much sense IMO. People shouldn't use the constructor at all; they should use DOMMatrix instead.

And then in theory we can just delete this whole thing from the compat spec, once the small issues are worked out?

Yep. Please file any bugs on the Geometry spec (link in bottom right corner of the spec).

[miketaylr]

As for the "parse transform lists as a transform property" problem (issue #34), what do you think makes more sense -- leaving the DOMMatrix spec as-is

Yes. See #34 (comment)

Oh, right. That reply got buried in my GitHub issues email folder. Agreed DOMMatrix shouldn't change that.

That doesn't make much sense IMO. People shouldn't use the constructor at all; they should use DOMMatrix instead.

Yes, nobody should be using WebKitCSSMatrix for new content (though that's probably not true today as only one engine supports (an older version of) DOMMatrix.

My concern is more about documenting how to parse WebKitCSSMatrix(transformList) for implementations that don't yet support the DOMMatrix alias (which is all of them) or a backwards compatible SVG transform attribute -> CSS transform property syntax. But you're right, that doesn't make sense in the DOMMatrix spec.

One option is to update the compat spec to reflect the current state of what Gecko has (or will soon have, when 1241575 is fixed), and add a note pointing future implementers to DOMMatrix instead. And then nuke the whole thing at some point in the future (maybe that future is immediately after the spec updates are in git history).

[miketaylr]

Given #19 (comment), I think we can close this. 🎈

[foolip]

Chromium bug: https://code.google.com/p/chromium/issues/detail?id=581955

[grorg]

Thanks for this. I'll file a bug for WebKit to follow along (and implement DOMMatrix as well).

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

[miketaylr]

Here's one issue I missed (around rotateAxisAngle): https://bugzilla.mozilla.org/show_bug.cgi?id=1245242. I'll file an issue on DOMMatrix but wanted to record it here.

(As I said in the bug, there doesn't seem to be a huge usage of rotateAxisAngle out in the wild, from what I can tell -- but we should aim for compatibility)

[miketaylr]

@zcorpan help my matrix-fried brain out. According to the Geometry spec's definition of DOMMatrixReadOnly.rotateAxisAngleSelf, should m and m3 produce the same result? If so, it's just a Gecko bug.

m = new DOMMatrix()
m2 = m.rotateAxisAngle(0.707, 0.707, 0.707, 45)
m3 = new WebKitCSSMatrix('rotate3d(0.707, 0.707, 0.707, 45deg)')

[zcorpan]

I think they should be the same.

[miketaylr]

Yep, was a Gecko bug -- false alarm. The fix should be in tomorrow's nightly.

🚒