This reverts e7890429aa and partly reverts
a59c15481f.
The one pseudo-class that accepted multiple of these was :heading(), and
since that got changed to take integers instead, there's no need to keep
this extra complexity (and memory usage) around.
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).
`StyleValue`s stored within `ComputedProperties` should be in their
computed forms, this is for various reasons including:
- Inheritance should be of computed values
- Animations should work on computed values
- Triggering transitions should work on computed values
Currently we store `StyleValue`s in an absolutized version of the
specified value - this is equivalent to the computed form in many cases
which is why this hasn't been causing significant issues but there are
some cases - such as `border-*-width` keywords where this is not the
case.
No functionality change as we are yet to implement any properties
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 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`.
And make it a DOM::Node, not DOM::Element. This makes everything flow
much better, such as spec texts that explicitly mention "focused area"
as the fact that we don't necessarily need to traverse a tree of
elements, since a Node can be focusable as well.
Eventually this will need to be a struct with a separate "focused area"
and "DOM anchor", but this change will make it easier to achieve that.
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
