`border-radius` requires a slash between the x/y components, but the
longhands like `border-top-left-radius` don't allow it. This spec
change allows authors to put a slash there for consistency.
Corresponds to:
e938d7d705
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`
Previously we would either parse these as `StyleValueList<T>` or `T`
depending on whether or not there was more than one value, this meant we
always had to handle both cases anywhere we used these values.
The remaining failing tests in view-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.
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.
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
