This exposes an existing issue with interpolation where it is not clear
in what situations zero-valued dimensions should be excluded from the
interpolated value of a dimension-percentage mix (e.g. `calc(50% + 0px)`
vs `50%`) - but this is just a serialization issue as both
representations are resolved to the same used value
The spec asks us to serialize with no more than 6 decimal digits, so if
the number is smaller than 0.000,000,5 then it can't produce any digits
and we should serialize it as 0, instead of using scientific notation.
We also shouldn't use scientific notation for very large numbers, but we
don't seem to have a flag to disable that in the formatter, so I'm
leaving a FIXME for now.
Improves some test results. 🎉
...when the style is `none` or `hidden`. `outline-width` is not affected
by `outline-style: none` at all.
In our codebase, that means doing the border-width conversion when
assigning to ComputedValues.
Corresponds to:
2a3d1e4d1009f11f2ef9
Some subtests changed in response to this CSSWG resolution:
https://github.com/w3c/csswg-drafts/issues/11494#issuecomment-2675800489
Basically, `border-style: none` now affects the used value of
`border-width`, not the computed value. (And the same for `outline`
properties.)
This affects way more tests than I expected because
interpolation-testcommon.js now adds tests for composition.
If we are interpolating between a dimension and a percentage value and
the dimension component is 0, we now return a percentage value rather
than a `calc()` value.
All remaining failing subtests in border-image-width-interpolation.html
are related to incorrect handling of mixed dimension and percentage
interpolation and are fixed by #6142.
We also support interpolating from a CalculatedStyleValue to a
compatible dimension or percentage style value.
This also brings with it a couple of improvements in how we handle
interpolation between mixed dimension and percentage types in terms of:
- Proper simplification of the resulting calc()
- Improved handling of interpolation outside the 0-1 range
...instead of `auto` Lengths.
This also fixes interpolating between two `auto` `<bg-size>`s, which
fixes a lot of animation tests for both `background-size` and `mask`.
Gains us 112 new passes since we now interpolate keywords (thick, thin,
etc) correctly.
Also loses us 4 WPT tests as we longer clamp negative values produced by
interpolation from the point of view of getComputedStyle (although the
'used' value is still clamped).
This removes the AnimationRefresh argument from `collect_animation_into`
which was added in a9b8840 - it's only effect was disallowing
`UseInitial`s within keyframes when we were doing animated style
updates which I believe is unintentional.
Gains us 214 WPT tests.
We now clamp the values returned from calc into the allowed range (where
we know it) and censor any `NaN`s to `0` both when we resolve and when
we serialize.
Gains us 76 WPT passes.
This fixes an issue where only the last KeyframeEffect applied to an
element would actually have an effect on the computed properties.
It was particularly noticeable when animating a shorthand property like
border-width, since only one of the border edges would have its width
actually animate.
By deferring the invalidation until all animations have been processed,
we also reduce the amount of work that gets done on pages with many
animations/transitions per element. Discord is very fond of this for
example.
If a property is uses discrete interpolation and TransitionBehavior is
not set to `AllowDiscrete` that property should be non-transitionable.
This is now true for properties whose animation type is not discrete,
but the animation type falls back to discrete.
