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.
We shouldn't include spread distance when serializing `text-shadow` as
it is not supported unlike `box-shadow` - to achieve this we store
whether this is a text or box shadow within the ShadowStyleValue and
serialize appropriately.
This introduces the `TextUnderlinePositionStyleValue` class, it is
possible to represent `text-underline-position` as a `StyleValueList`
but would have required ugly workarounds for either serialization or in
`ComputedProperties::text_underline_position`
This is an arbitrary set of tests intended to cover the different
CSSStyleValue types without too much overlap.
Right now they all fail, because testsuite.js attempts to create one of
every type of CSSStyleValue on load, and we don't have most of them.
When we have a `calc` which is a mix of a dimension and a percentage, we
should use the percentage alone for the computed value if the dimension
component is 0 e.g. `calc(50% + 0px)` should use `50%` as it's computed
value.
Transitions apply after logical properties are mapped to their physical
counterparts so we should apply this mapping to `transition` properties
Gains us 20 WPT tests.
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.
This also fixes a bug in the view transitions code that was
required to get the imported test to pass. The code for setting
the initial containing block size just did not set the right thing,
since doing so would trigger an error later on.
That later error resulted from walking up the tree, without
considering that the document element has a parent that is not
itself an element. (and then doing element things to it)
This change removes premature reset of
`block_container_y_position_update_callback`. Also makes callback
private in `BlockMarginState`, because resetting it independently of
currently accumulated margins is incorrect.
Lots of test expectations are updated, but there is no visual
difference.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/6074
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
This behaviour should only apply to literal percentages as clarified
here: https://github.com/w3c/csswg-drafts/commit/4ee8429
We were also doing this wrong by converting the numeric type of the calc
to Length which was causing values to be defaulted to 1 instead (hence
the new passing tests for computed values as well)
This ensures that we clamp values for properties like padding-* to valid
ranges (non-negative in this case) if they are specified with `calc()`.
The length-related changes in this commit combined with the ones from
the previous commit fix the primary layout issue on https://lwn.net
(yes, not the first place I would have expected problems either).
...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`.
