We can deduplicate some code by using `assemble_coordinated_value_list`,
also moves this to a method in `ComputedProperties` to be in line with
other values
This is required after e937f5d - it went unnoticed until now since the
serialization is the same and the relevant code just fell back to it's
own defaults which were the same.
This makes us consistent with how we handle this value within the
`background` shorthand and allows us to remove the special handling in
`StyleComputer::for_each_property_expanding_shorthands`
This is handled by the generic logic for parsing positional value list
shorthands once we register the legacy value alias of `overlay>auto` on
the shorthand as well as longhand properties.
Some of the remaining coordinating value list properties (e.g.
transition-property) require custom handling as they are not always
simple comma separated lists but others (e.g. background-size) can be
removed if we promote their relevant syntax to a `ValueType`
This specifically includes a `!important` for `overflow: clip`, which
makes sure an `<input>`'s contents cannot easily be made to overflow its
boundaries.
Computing the font for an element in `compute_font` is premature since
we are yet to apply animated properties - instead we should compute the
value on the fly (with a cache to avoid unnecessary work) to ensure we
are respecting the latest values
Font computation and loading is distinct enough from style computation
that it makes more sense to have this in it's own class.
This will be useful later when we move the font loading process to
`ComputedProperties` in order to respect animated values.
Since we resolve any relative lengths at compute time there's no need
for the value to be passed around as a `NumberOrCalculated` and we can
just resolve it within `ComputedProperties::font_variation_settings`.
The only place this is used it is used with value_or so there's no need
to return it is an `Optional`.
This is only used for loading fonts (which occurs during style
computation) so there's no need to store it in `ComputedValues`
Having the dumping code in a separate Dump.cpp meant that it was often
overlooked when the rules gained new features, and also limits dumping
to publicly-accessible information.
From the spec:
> The owning element of a transition refers to the element or
pseudo-element to which the transition-property property was applied
that generated the animation.
https://drafts.csswg.org/css-transitions-2/#owning-element
Previously we only stored the element.
Fixes some WPT tests that expected `supports(foo:bar)` to serialize as
`supports(foo:bar)`, instead of `supports(foo: bar)` with a space
between.
Reading the original_full_text directly also lets us delete
Declaration::to_string(), which was only used here.
In some situations we want to examine a sequence of tokens that have
been already consumed from a TokenStream. These methods let us do so:
- current_index() provides the current internal token index
- tokens_since() provides a span from the given index to the current one
The previous implementation assumed that the contents of `supports()`
was either a raw declaration, or a block containing some number of them.
This meant we wouldn't parse things like `supports(not (a:b))` or
`supports(selector(*))`.
`parse_a_supports()` actually does what we want in every case except for
raw declarations (`supports(a: b)`), so let's always call it first, and
then fall back to parsing a single declaration.
The spec says:
> For the purpose of this specification, they all have the same effect
as auto. However, the host language may also take these values into
account when defining the native appearance of the element.
https://drafts.csswg.org/css-ui/#typedef-appearance-compat-special
Firefox at least hides the stepper buttons when this is set.
This lets us not care about non-absolute Length units when resolving
gradient data, as they'll already have been converted to px.
We can also use Angle::from_style_value() safely on absolutized angles,
which reduces some boilerplate code.
A few things fall out of this:
- We no longer need to templatize our color-stop list types.
- A bit more code is required to resolve gradient data.
This results in a slightly different rendering for a couple of the test
gradients, with a larger difference between macOS and Linux. I've
expanded the fuzziness factor to cover for it.
This works by generating random values using XorShift128PlusRNG at
compute time and then caching them on the document using the relevant
random-caching-key
