CSSTransformComponents hold other CSSStyleValues as their parameters. We
want to be able to create internal representations from those parameters
without them caring if they would be valid when directly assigned to the
property.
This is a temporary solution to make transform functions work. To be
completely correct, we need to know what is allowed in that context,
along with value ranges - a combination of the contexts we create when
parsing, and when computing calculations. For transform functions, this
doesn't matter, as there's no limit to the range of allowed values.
Unfortunately this doesn't pass a lot of tests, because we strip out
whitespace when parsing property values. In particular, the WPT suite
tests with this:
```js
new CSSUnparsedValue([' ', new CSSVariableReferenceValue('--A')])
```
...which gets the whitespace stripped from the string, meaning when we
convert the value back to JS, we get the equivalent of this:
```js
new CSSUnparsedValue(['', new CSSVariableReferenceValue('--A')])
```
...and that's not the same so the test fails.
As noted in the linked spec issue, it's possible for an author to
construct a CSSUnparsedValue that contains itself, meaning
serialization would be infinitely recursive. So instead, detect that
and then return an empty string, which copies Blink's solution to this
issue.
Stops `css/css-typed-om/cycle-in-unparsed-value-crash.html` from
crashing after we implement converting a CSSUnparsedValue to an
UnresolvedStyleValue, as that relies on serialization.
DOMMatrix.to_string() throws exceptions if any of its values are
non-finite. This ends up affecting CSSStyleValue because its subclass
CSSTransformValue (which is about to be added) serializes
CSSTransformComponents, and one of those is CSSMatrixComponent, which
calls DOMMatrix.to_string().
This is all quite unfortunate, and because at the time the spec for
DOMMatrix was written, CSS couldn't represent NaN or infinity. That's
no longer true, so I'm hoping the spec can be updated and this can be
reverted. https://github.com/w3c/fxtf-drafts/issues/611
We don't serialize these the way WPT expects, because we don't implement
the comment-insertion rules from CSS-Syntax. We don't implement that
for regular serialization either, so it's something we can worry about
later.
