Previously, some StyleValues created a large number of intermediate
strings during serialization. Passing a StringBUilder into the
serialization function allows us to avoid a large number of these
unnecessary allocations.
The Transformation class wasn't really accomplishing anything. It still
had to store StyleValues, so it was basically the same as
TransformationStyleValue, with extra steps to convert from one to the
other. So... let's just use TransformationStyleValue instead!
Apart from moving code around, the behavior has changed a bit. We now
actually acknowledge unresolvable parameters and return an error when
we try to produce a matrix from them. Previously we just skipped over
them, which was pretty wrong. This gets us an extra pass in the
typed-om test.
We also get some slightly different results with our transform
serialization, because we're not converting to CSSPixels and back.
Some transform-functions are not reifiable as a CSSTransformComponent,
for example a matrix() with sibling-index() in it. In that case, rather
than crashing, fall back to the basic CSSStyleValue reification.
The crash doesn't happen yet, but would with the following commit's
changes. Currently, Transformation::to_matrix() completely ignores
unsupported argument types, but in the next commit that's replaced with
TransformationStyleValue::to_matrix(), which attempts to handle them
properly.
We had a partial implementation of transformation function interpolation
that did not support numerical interpolation of simple functions (e.g.
`scale(0)` -> `scale(1)`). This refactors the interpolation to follow
the spec more closely.
Gains us 267 WPT subtest passes in `css/css-transforms`.
Fixes#6774.
Since we now have access to the `AbstractElement` through the
`ComputationContext` we can just set the flag that this element relies
on tree counting functions directly, no need to pass this struct around.
We have a slightly odd setup here. TransformationStyleValue reifies as a
single CSSTransformComponent. It's StyleValueList that actually reifies
as a CSSTransformValue - but only if it only contains
TransformationStyleValues.
+79 WPT subtests.
This reverts 0e3487b9ab.
Back when I made that change, I thought we could make our StyleValue
classes match the typed-om definitions directly. However, they have
different requirements. Typed-om types need to be mutable and GCed,
whereas StyleValues are immutable and ideally wouldn't require a JS VM.
While I was already making such a cataclysmic change, I've moved it into
the StyleValues directory, because it *not* being there has bothered me
for a long time. 😅
The only ways this varies from the `scale()` function is with parsing
and serialization. Parsing stays separate, and serialization is done by
telling `TransformationStyleValue` which property it is, and overriding
its normal `to_string()` code for properties other than `transform`.
