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.
When setting style to a CSSStyleValue we need to convert it to a
StyleValue. If we already have one, we might as well use it avoid the
work of serialization and re-parsing.
I realised I misunderstood what "constructed from a USVString" means, so
I've adjusted based on that. It does raise a question on what the source
USVString is if that string resulted in multiple CSSStyleValues being
created - see the linked issue.
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
