`EdgeStyleValues` which consist of an offset of a `calc()`s which
resolves to 50% should be considered "centered" for
`SerializationMode::ResolvedValue` for the purpose of omitting the
position value from gradient serialization.
As well as being required to implement absolutization this also means we
now bypass a limitation with `LengthPercentage` where we would always
use `SerializationMode::Normal` for the constituent lengths which gains
us some WPT passes
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.
This is equivalent to the existing `PositionStyleValue::create_center`
but returns the value expected after computation has been completed
(i.e. `50% 50%` rather than `center center`)
Previously this was implemented inline within the parsing of
`{repeating}-radial-gradient()` functions but it will also be useful for
`circle()` and `ellipse()`.
We now support the CSS Images Module Level 4 additions to the
`<radial-size>` syntax, namely:
- `<length-percentage>` rather than just `<length>` for circles.
- Distinct `<radial-extent>` values for horizontal and vertical for
ellipses.
- Mixing of `<radial-extent>` and `<length-percentage>` values for
ellipses.
The regressions are due to WPT not being updated to expect the first of
these additions.
This also allows us to remove the path generation and interpolation
handling for `rect()` and `xywh()` since that occurs after computation
Regressions in clip-path-interpolation-xywh.html are due to improper
simplification of length-percentage mixes where the length is 0px.
Storing these within `LengthPercentage`, `LengthBox`, and `Variant`
over-complicated things.
We also now use the correct `SerializationMode` when serializing `xywh`
and `rect`
This lets us not care about non-absolute Length units when resolving
gradient data, as they'll already have been converted to px.
We can also use Angle::from_style_value() safely on absolutized angles,
which reduces some boilerplate code.
A few things fall out of this:
- We no longer need to templatize our color-stop list types.
- A bit more code is required to resolve gradient data.
This results in a slightly different rendering for a couple of the test
gradients, with a larger difference between macOS and Linux. I've
expanded the fuzziness factor to cover for it.
This works by generating random values using XorShift128PlusRNG at
compute time and then caching them on the document using the relevant
random-caching-key
We know that longhand values are always `StyleValueList`s
Introduces a new fail in the `view-timeline-shorthand.html` WPT test
but this is because the test is incorrect and we now correctly don't
contract when `view-timeline-inset` has dissimilar cardinality. See
web-platform-tests/wpt#56181
The remaining failing tests in view-timeline-shorthand.html are due to
either:
a) incorrect tests, see web-platform-tests/wpt#56181 or;
b) a wider issue where we collapse coordinating value list longhand
properties to a single value when we shouldn't.
The remaining failing tests in scroll-timeline-shorthand.html are due to
either:
a) incorrect tests, see web-platform-tests/wpt#56181 or;
b) a wider issue where we collapse coordinating value list longhand
properties to a single value when we shouldn't.
