This struct will in the future hold information other than a length
resolution context (e.g. context for tree counting functions) and a
single struct is easier to work with than multiple parameters.
This commit modifies the `compute_foo()` code for `font-style` and
`math-depth`. They previously assumed that their StyleValue was always
a special kind: FontStyleStyleValue or MathDepthStyleValue. This was
always true, because that's how we parse them, but it stops being true
once StylePropertyMap is involved: An author can set font-style to a
CSSKeywordValue of "italic", and this should work.
There are multiple ways that we could solve this, but the simplest and
easiest to maintain seems to be to handle those more basic StyleValues
in this computation code. Going forward, we'll have to be aware that
similar properties could have a basic StyleValue from the typed-OM
instead of the property-specific one we'd expect.
Whether an absbox is positioned below or to the right of its previous
sibling in an `InlineFormattingContext` is determined by the
display-outside value before blockification, so we store the
pre-blockification `display` value in `ComputedValues` to access it in
`InlineFormattingContext` and position the box accordingly.
Opacity values are unique in that the range which calculated and
interpolated values should be clamped to [0,1] is different from the
range of allowed values [-∞,∞].
This fixes 28 WPT tests that were regressed in #6112
We were unnecessarily computing property values within
`collect_animation_into` which we can avoid by ensuring that all calls
to `collect_animation_into` happen after property values are computed.
We now fail a few more tests in properties-value-inherit-001.txt as we
no longer overwrite the non-animated value of `line-height` with the
animated value, this is in line with other major browsers.
We were already doing this within `compute_property_values` where
we resolved most relative lengths but the remainder was instead
incorrectly using the font's line-spacing
Previously if we would overwrite the non-animated font-size with the
animated font-size if it was set.
Loses us 2 WPT tests but this is in line with other browsers
We now also more closely follow the spec when computing values for
font-weight and we now:
- Support relative lengths in `calc()`s
- Properly clamp `calc()`s
- Support relative keywords (e.g. lighter, bolder)
- Respect that font-weight can be a non-integer number.
This does expose a few false positives in the font-weight-computed.html
WPT test. This is because we don't recompute non-inherited font-weight
within `recompute_inherited_style` which means that relative keyword
values can fall out of sync with their parent's value. These previously
passed as we treated `bolder` and `lighter` as aliases for `bold` and
`normal` respectively.
Remaining test failures in font-size-interpolation-00* are either:
- Rounding of font-size to CSSPixels when setting the expected value
- Not clamping negative values from the point of view of
getComputedStyle (used values are still clamped)
Previously if we would overwrite the non-animated font-size with the
animated font-size if it was set.
Gains us 8 WPT tests and means we now fail 9 others in line with other
browsers.
There are other places we want to convert font-size into it's computed
form than just when we are loading the font (e.g. computing keyframes).
Gains us 36 WPT passes as we now correctly clamp negative calc values.
A new parameter was added to Web::CSS::StyleValue::to_string() in
PR #2820 but this debug message was never updated. If
CSS_TRANSITIONS_DEBUG was enabled, compilation would fail.
As noted, the chunk of this method that deals with animations could do
with some helpers on AbstractElement, but I'm leaving that until it's
clearer how animations and pseudo-elements should interact.
