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 fixes a silly bug where we would crash when parsing a multi-layer
mask shorthand property that contained the no-clip keyword but no value
for mask-origin.
Fixes a crash when parsing the CSS of https://www.browserbase.com/. The
site still has other, unrelated problems though.
We don't need all this specific logic for parsing the `transition`
property - we also now maintain `none` as such until use time which
gains us a couple extra tests
Adds support for `sibling-index()` and `sibling-count()` when parsing
`<number>` and `<integer>`. This is achieved by a new
`TreeCountingFunctionStyleValue` class which is converted within
`absolutized` to `NumberStyleValue` and `IntegerStyleValue` respectively
There are still a few kinks to work out in order to support these
everywhere, namely:
- There are some `StyleValue`s which aren't absolutized (i.e. those
which are stored within another `StyleValue` without an
`absolutize()` method.
- We don't have a way to represent this new `StyleValue` within
`{Number,Integer}OrCalculated`. This would be fixed if we were to
instead just use the `StyleValue` classes until style computation at
which time they would be absolutized into their respective
primitives (double, i64, etc) bypassing the need for *OrCalculated
entirely.
We no longer rely on parsing easing functions before keywords so this
can be moved down with the other parse_for_type calls.
`parse_for_type` is used for more than just parsing easing functions so
the variable name `maybe_easing_function` was misleading
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.
property_accepts_type() only looks at the property itself, not any
longhands it might have, so we thought that `font` didn't accept
`<custom-ident>`s, and seeing "-apple-..." makes us throw out the
declaration even though it's valid as a font name.
We'll reject these like any other unrecognized value if it's somewhere
that's not supported, so this was really just an optimization for a
rare edge case, and removing the check doesn't have any observable
effect except fixing this bug and any similar cases.
Changing property_accepts_type() to look at longhands is not
straightforward, as not all longhand values are valid in the shorthand.
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.
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.
We shouldn't include spread distance when serializing `text-shadow` as
it is not supported unlike `box-shadow` - to achieve this we store
whether this is a text or box shadow within the ShadowStyleValue and
serialize appropriately.
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`
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.
Previously we would instead parse these as single values and rely on
ad-hoc functionality in `for_each_property_expanding_shorthands` to
expand them to longhands.
This gets us a step closer to removing that ad-hoc functionality.
This behaviour should only apply to literal percentages as clarified
here: 4ee8429
We were also doing this wrong by converting the numeric type of the calc
to Length which was causing values to be defaulted to 1 instead (hence
the new passing tests for computed values as well)
...instead of `auto` Lengths.
This also fixes interpolating between two `auto` `<bg-size>`s, which
fixes a lot of animation tests for both `background-size` and `mask`.
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".
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.
