[geometry] DOMMatrix stringifier in workers

[zcorpan]

https://drafts.fxtf.org/geometry/#dom-dommatrixreadonly-stringifier

stringifier()
If is2D is true
Return a DOMString in the form of a CSS Transforms <matrix()> function where a is a attribute, b is b attribute, c is c attribute, d is d attribute, e is e attribute, f is f attribute. [CSS3-TRANSFORMS]
Otherwise
Return a DOMString in the form of a CSS Transforms <matrix3d()> function where m11 to m44 are set to m11 to m44 attributes. [CSS3-TRANSFORMS]

In #122 we limited CSS parser entry points for DOMMatrix to Window. Should we also limit the stringifier to Window (so that in workers it would stringify to "[object DOMMatrix]")?

cc @esprehn @chrishtr @foolip

[foolip]

At a glance I can't tell if [Exposed=Window] stringifier is allowed in Web IDL, but my initial reaction is that there wouldn't be much point in limiting this. The serialization code path seems to be standalone, and so making it work would be less work that limiting it, I think.

[chrishtr]

I think we should limit the special stringifier to the main thread, and return [object DOMMatrix]
in workers. Reasons: symmetry, simplicity for implementors.

[foolip]

I wouldn't really mind that, but isn't it actually more complicated for implementors?

[zcorpan]

Another aspect is that #120 proposes making the stringifier throw if there are NaN/Infinity values, which could be nice to avoid in workers.

[zcorpan]

As far as I can tell from WebIDL, [Exposed=Window] stringifier; should work. stringifier; is shorthand for stringifier DOMString ();, which is an interface member, and [Exposed] applies to interface members.

[foolip]

If [Exposed=Window] stringifier works, then that SGTM, no custom bindings or anything funny needed.