Removing all whitespace before parsing StyleValues seemed like a good
idea back when I did it, but causes issues. Serialization cares about
whether there was whitespace or not, and we also weren't removing
whitespace from inside blocks and functions so it was inconsistent
whether we needed to deal with whitespace or not.
So currently, some parsing code is conscious of whitespace, some isn't,
and some tries to be but is incorrect. Rather than try to fix all of
this in a single large, messy change, this commit introduces
a "strip-whitespace" flag to Properties.json. We can then disable
whitespace-stripping a few properties at a time and debug any issues
more easily. Eventually (hopefully soon), this will go away entirely.
There were a couple places that we had special handling for the `all`
property but since d31a58a was merged we can treat it the same as any
other shorthand
This excludes `step-end` and `step-start` which are expected to be
converted to the equivalent function at parse time.
We are expected to serialize these as the explicit keywords - previously
we would parse as `EasingStyleValue` and serialize equivalent functions
as the keywords. This caused issues as we would incorrectly serialize
even explicit functions as the keyword.
This also allows us to move the magic easing functions to
`EasingFunction` rather than `EasingStyleValue` which is a bit tidier
The `transform` property is now parsed based on its JSON data, and
shouldn't behave any differently than before.
This makes `<transform-list>` and `<transform-function>` work in the
`syntax` descriptor for `@property`, and also means we know that
`transform` can accept the `none` keyword. We get a few WPT passes out
of that.
Typed-OM requires us to have a generic way of asking "does property X
accept a list or a single value?" so this exists mainly for that.
Coordinating lists are annotated too - I'm not clear on exactly what
will be needed for those, but giving them a unique value now at the
worst will make them easier to find later.
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.
We now:
- Serialize longhands in the correct order
- Support serializing multiple values
- Include default longhands where required (to distinguish
animation-name from that longhand).
This change adds the allowed angle range to the `font-style` property
definition. This allows these angles to be clamped after interpolation.
Ideally, the generator should be updated so that we can specify the
angle is in degrees. This would allow us to make use of this
information during parsing, which we can't do currently because we
don't know what the unit is. Using this value for interpolation
purposes is fine because the angle has been converted to its canonical
unit by this point.
This introduces the `TextUnderlinePositionStyleValue` class, it is
possible to represent `text-underline-position` as a `StyleValueList`
but would have required ugly workarounds for either serialization or in
`ComputedProperties::text_underline_position`
Omitting the `/`s meant that `1` and `0` were parsed as part of
border-slice instead of their intended values.
No functional changes but this will be relied on in a later commit.
Some properties like `justify-items`, `grid`, or `display` do affect
layout, but their used values can be obtained without performing a
layout calculation.
This change introduces a new helper,
`property_needs_layout_for_getcomputedstyle()`, specifically for use by
`CSSStyleProperties::property()`. It returns true only for properties
such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where
an up-to-date layout is required to return the correct used value.
All remaining failing subtests in border-image-width-interpolation.html
are related to incorrect handling of mixed dimension and percentage
interpolation and are fixed by #6142.
Continues the work started in #5386 to simplify handling of positional
value list shorthand properties.
Previously we would parse these as `StyleValueList`s and then rely on
`StyleComputer::for_each_property_expanding_shorthands` to expand them
into longhands.
This required a bit of work to handle `ShorthandStyleValue`s for the
`@page` `margin` descriptor.
