`font-size` can end up with a negative value - either due to `calc`
being resolved using the old method which doesn't clamp the value, or
interpolation - in this case we should clamp negative values to zero.
Gains us 36 new WPT passes and fixes crashes in the three imported
tests.
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
What I thought was a spec issue was actually a combination of my own
misunderstanding and a bug in our IDL generator. With that bug fixed, I
can correct this to how it is in the spec.
Reifying the result gets quite ad-hoc. Firstly because "parse a
component value" produces a ComponentValue, not a full StyleValue like
we need for math functions. And second, because not all math functions
can be reified as a CSSNumericValue:
Besides the fact that I haven't implemented CalculatedStyleValue
reification at all yet, there are a lot of math functions with no
corresponding CSSMathValue in the spec yet. If the calculation tree
contains any of those, the best we can do is reify as a CSSStyleValue,
and that isn't a valid return value from CSSNumericValue.parse(). So, I
made us throw a SyntaxError in those cases. This seems to match
Chrome's behaviour. Spec issue:
https://github.com/w3c/css-houdini-drafts/issues/1090
We originally had special handling for `:host()` as that had been the
only pseudo-class that could be both an identifier or a function.
However, this meant duplicating the serialization logic, and also we
had to manually remember to add the same hack for any other
identifier-and-function cases. Which I forgot to do with `:heading()`!
So instead, for these cases, detect if they actually have arguments
specified and use that to determine which form to serialize as. We do
still have to write a check for each one of these pseudo-classes, but
the VERIFY should make it easier to remember.
We now also store `outline-width` in ComputedValues as a `CSSPixels`
since we know it's an absolute length at `apply_style` time - this saves
us some work in converting to CSSPixels during layout.
Gains us 46 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).
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.
The transform of each paintable was being applied multiple times due to
the recursive nature of the hit testing methods. Previously it used
combined_css_transform to transform the position, and then it would pass
that position to children, which would then apply combined_css_transform
again, and so on.
PaintableBoxes are also not hit tested anymore when having a stacking
context. A similar check is done in PaintableWithLines, but it was
missing from PaintableBox. Without this check some elements can get
returned multiple times from a hit test.
StackingContexts with zero opacity will now also get hit tested, as it
should have been before.
If an animation got to its finished state before its target's computed
properties could be updated, we would end up with invalid styles. Do not
skip finished animations, but prevent effect invalidation on timeline
updates if the animation is already finished.
This fixes the CI flake on WPT test
`css/css-transitions/inherit-height-transition.html`.
Now elements with position `absolute` properly resolve their position
inside parent elements with `grid`. I also imported some WPT tests
related to that topic.
Part 2 of resolving issues on https://hack4krak.pl
Fixes bug when we didn't use `tracks_to_grow_beyond_limits` and instead
distributed extra space to all affected tracks. Also implements missing
"when accommodating max-content" part.
We don't serialize these the way WPT expects, because we don't implement
the comment-insertion rules from CSS-Syntax. We don't implement that
for regular serialization either, so it's something we can worry about
later.
The "subdivide into iterations" part is left as a FIXME for now, until
we have a way of knowing if a property is a list or not.
The parse_a_css_style_value() helper has an unwieldy return type because
of the requirement that it return either one value or a list of values,
but sticking to the spec here seems worthwhile for now.
For us, that's KeywordStyleValue and CustomIdentStyleValue.
CustomIdentStyleValue now has a .cpp file to reduce the number of
includes in its header file.
CSSStyleValue is adjusted to allow for subclasses. Serialization for
CSSKeywordValue is implemented differently than the spec says because
of a spec bug: https://github.com/w3c/csswg-drafts/issues/12545
This changes the maximum number of decimal places from 5 to 6, but 5 was
previously a guess, and not specified behaviour:
> For all of the decimal changes (except color) I couldn't really find a
> spec that mandates any required precision, so I just copied what
> Firefox seems to do, which is limit the output to 5 decimal places.
> https://github.com/SerenityOS/serenity/pull/23449
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.
When starting transitions we compute the after-change style, for any
inherited properties this should include the non-animated value.
Previously we were only inheriting the animated value and treating it as
non-animated so were instead including the animated value.
This commit fixes that by inheriting both the animated and non-animated
values (with the former being stored in `m_animated_property_values`,
and the latter in `m_property_values`).
This gains us 12 new WPT passes.
This brings with it 252 new WPT fails from the various 'events' tests in
css/css-transitions/properties-value-inherit-001.html, however these
also fail in other browsers (Chrome, Edge and Firefox) and the behaviour
that causes these failures is specifically mentioned in the spec.
This commit updates the CSSTransition constructor to:
- Leave the KeyframeEffect start time unresolved
- Set the KeyframeEffect start delay
Gains us 14 WPT passes but exposes one false positive in
properties-value-inherit-001.html
The limitations right now are:
- We don't know if a property is a list or not.
- We always reify as a CSSStyleValue directly.
So, we pass some tests but only ones that expect a CSSStyleValue.
After looking into this more, the `[[declarations]]` slot does not seem
to need to be a literal map of property names and values. Instead, it
can just point at the source (an element or style declaration), and
then direct all read or write operations to that.
This means the `has()` and `delete()` methods actually work now.
A few remaining failures in these tests are because of:
- StylePropertyMap[ReadOnly]s not being iterable yet
- We're not populating an element's custom properties map, which get
fixed whenever someone gets around to producing proper computed
values of them.
This is everything except some failing ref-tests, and
`css/css-typed-om/the-stylepropertymap/properties/*` because importing
a test for every property feels excessive.
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.