The remaining failing tests in scroll-timeline-shorthand.html are due to
either:
a) incorrect tests, see web-platform-tests/wpt#56181 or;
b) a wider issue where we collapse coordinating value list longhand
properties to a single value when we shouldn't.
CSS Text 3 gives `text-indent` a couple of optional keywords to control
which lines are affected. This commit parses them, but doesn't yet do
anything with them.
The rules for strings here are:
- 4 ASCII characters long
- Shorter ones are right-padded with spaces before use
- Trailing whitespace is always removed when serializing
We previously always padded them during parsing, which was incorrect.
This commit flips it around so we trim trailing whitespace when parsing.
We don't yet actually use this property's value for anything. Once we do
so, maybe we'll care more about them being stored as 4 characters
always, but for now this avoids us needing a special step during
computation.
Fixes a crash on https://www.lego.com/en-gb/product/game-boy-72046 :^)
The apparent regressions in clip-path-interpolation-xywh-rect.html are
because of false positives. Something about the test was causing it to
compare two wrong values that happened to be the same. Now one of the
values is correct, they don't match.
In a few places, user code wants to parse a `<color>` or `<length>` etc,
but we didn't have a way to do so, so they would do something
similar-ish instead, like parse the value of the `color` property.
Let's make that available instead.
This updates the `parse_text_decoration_line_value` to reject values
which non-exclusively include `none` e.g. `underline none`.
It also simplifies handling by always producing a Vector (except for
`none`) and adding VERIFY_NOT_REACHED in more places which shouldn't be
reachable.
Now that we don't strip out whitespace, this method was copying the
input TokenStream into a Vector, and then creating new TokenStreams
from that. So, stop doing that and use the input TokenStream instead.
To make this a bit easier, we now wrap the per-property parsing
functions in a parse_all_as() lambda, which skips whitespace, and
returns an error if parsing failed or there are trailing tokens.
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
Since we now have access to the `AbstractElement` through the
`ComputationContext` we can just set the flag that this element relies
on tree counting functions directly, no need to pass this struct around.
There are some non-math functions (such as tree counting functions)
which we should allow within `calc()`s . This commit implements the
initial infrastructure for this.
We don't yet parse any of these non-math functions in
`parse_a_calculation` so there is no functional change.
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.
Some contexts (e.g. descriptors, media conditions) don't allow tree
counting functions, this commit adds an easy way to check if the current
value context is one of those.
