This applies size, inline-size, and style containment in some cases.
There are other WPT tests for that, but we seem to not implement enough
of containment for this to have an effect so I've not imported those.
Gets us 35 WPT subtests.
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.
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 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)
This has always been a bit of a hack. Initially it made sense as a lot
of properties that accept a length also accept `auto`, but while
convenient, that leads to problems: It's easy to forget to check if a
length is `auto`, and places that don't accept it end up with an
invalid state lurking in the type system, which makes things unclear.
Not every user of this requires an `auto` state, but most do.
This has quite a big diff but most of that is mechanical:
LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`,
and `to_px_or_zero()` instead of `to_px()`, to make their output
clearer.
We only had one user of this which allows `auto`, which is length_box().
So, inline the code there, remove the `auto` branch from
length_percentage(), and then remove length_percentage_or_fallback()
entirely as nobody uses it any more.
1a3da3d introduced a crash as we assumed that font-size values were
always stored in their computed forms, this isn't correct for animated
font-size values.
As a temporary workaround until we store animated font-sizes in their
computed form we will return the non-animated value - this restores the
functionality prior to 1a3da3d
Interpolation can leave `padding-*` values as negative - this should be
handled by interpolation clamping it to the allowed range of values
but we don't yet do that. As a stop gap we can clamp this before setting
it in ComputedValues.
This fixes 3 crashes and gains us 11 passes in the imported WPT tests
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).
The StyleValue stored in m_property_values is already in it's computed
form and it's trivial to pull the underlying value out so there is no
need to store this separately.
Also removes unnecessary handling of percentage values in
`absolutize_values` - this is already handled within `compute_font`.
As `recompute_inherited_style` works in-place rather than building
ComputedProperties from scratch we need to keep track of which animated
properties are inherited to know whether we should remove them when we
have no more inherited value.
This property provides a hint to the rendering engine about properties
that are likely to change in the near future, allowing for early
optimizations to be applied.
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. 😅
Fixes crash in the created test as well as https://wpt.live/css/css-text
/word-spacing/reference/word-spacing-percent-001-ref.html. The WPT test
hasn't been imported as it passing is currently a false-positive due to
the fact that we don't yet respect `word-spacing` in most cases.
Taking a ColorResolutionContext directly instead of creating one from a
layout node allows us to call this from places where we don't have a
layout node.
Using a generic context argument will allow us to resolve colors in
places where we have all the required information but not in the form of
a layout node as was expected previously.
