The CSSNumericType defined in the spec is a simple dictionary which is
only used for OM purposes. This NumericType class is used internally
and matches the more abstract definition of a "type".
`StyleComputer::create_document_style` was the only place this wasn't
the case so we can remove the calls to
`compute_defaulted_property_value`. The call to
`compute_defaulted_values` in `create_document_style` is now redundant
so has been removed`
This was the last thing that `compute_defaulted_values` was doing when
called from here.
It also comes with the added benefit of us correctly inheriting animated
colors.
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.
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 partially reverts commit 3aff3327c4
by removing the code change but keeping the added test.
Now that paintables visibility caching has been reverted, this is no
longer doing anything except causing excessive relayouts on pages
like https://linear.app/
When serializing the "style" attribute, we were incorrectly assuming
that some of the grid-related CSS properties would never contain var()
substitution functions.
With this fixed, we can now book appointments on https://cal.com/ :^)
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
As of 7dc8062 paintables compute and cache their visibility (which
depends on opacity) at construction - this cached value can fall out of
sync with reality if if the opacity changes to/from zero within the
lifetime of that paintable.
This commit invalidates layout when an opacity changes to/from zero so
that we reconstruct paintables with the correct visibility.
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.
When no better reification form is available, we produce an opaque
CSSStyleValue with a serialized value. For starters, this will be the
only way to reify, and then we'll add others later.
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 isn't part of the CSSOM API directly, but will be used by
StylePropertyMapReadOnly.has() to avoid doing the work to serialize a
string version of the property's value, just to throw it away again.
Flex/grid items are always blockified (have their CSS display forced
into "block") by style computation.
We were doing this by looking at the CSS display of the parent. However,
if the parent has `display: contents`, we must look at the *grandparent*
instead.
This corrects the layout of buttons underneath Reddit article cards.
