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.
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
Previously we were doing this ad-hoc later in the process but we now
have the `calc` clamping system which can simplify things.
This reveals some false-positives in that we don't handle relative
lengths within these `calc`s but these are fixed in the next commit
