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.
This avoids regressions in the next commit.
See the linked spec issue for details. Without this, we end up doing the
wrong thing in cases like this, from a WPT test:
```js
styleMap.set('transition-duration', '1s', 'var(--A)');
```
`'var(--A)'` is a string, not a CSSVariableReferenceValue or
CSSUnparsedValue. Following the spec literally, we wouldn't throw a
TypeError here, even though we really should: The purpose of the check
is for list-valued properties, to prevent authors putting a series of
tokens that would represent multiple list items, into a single list
item slot.
So, we delay the check until after we've converted strings into values.
This does mean we're checking StyleValues instead of CSSStyleValues,
and it also means we've done more work before rejecting the input as
invalid. But correctness is nice. :^)
With this commit, only direct CSSStyleValues created from internal
StyleValues can be converted back to a StyleValue. More subtests will
pass as create_an_internal_representation() is implemented for the
various CSSStyleValue subclasses. :^)
Gets us... a LOT of WPT passes, because there's a ton of coverage for
each property.
After looking into this more, the `[[declarations]]` slot does not seem
to need to be a literal map of property names and values. Instead, it
can just point at the source (an element or style declaration), and
then direct all read or write operations to that.
This means the `has()` and `delete()` methods actually work now.
A few remaining failures in these tests are because of:
- StylePropertyMap[ReadOnly]s not being iterable yet
- We're not populating an element's custom properties map, which get
fixed whenever someone gets around to producing proper computed
values of them.
