We no longer try to resolve calculated values at parse time which means
we support relative lengths.
We now clamp negative values rather than rejecting them at parse time.
Parsing has been inlined into `parse_ratio_value` and `parse_ratio` has
been removed since `parse_ratio_value` was the only caller
See previous commit for details
We now support parsing of `display-p3-linear` (although it just falls
back to using Oklab since Skia doesn't support it)
Previously we had two implementations for parsing
`<color-interpolation-method>`, one for gradients and one for
`color-mix()` - this commit adds another which will unify the existing
ones in following commits.
This implementation has a couple of advantages over the existing ones:
- It is simpler in that it uses global CSS enums and their helper
functions
- It is spec compliant (unlike the `color-mix()` one which allows
arbitrary idents)
- It parses as a `StyleValue` which will be required once we support
`<custom-color-space>` since that can be an `ident()` which isn't
resolvable at parse time
Previously we parsed it as `<custom-ident>` in `<counter>` and as a
keyword in `list-style-type`.
The practical effect of this is:
- Spec defined counter style names in `<counter>` are ASCII lowercased
on parse.
- Non spec defined counter style names are allowed in `list-style-type.
We are still to parse the `symbols()` function but this gives us a
better base for that.
This means we now allow oblique angles when parsing the `font`
shorthand.
This also required us to rename the existing `FontStyle` enum to
`FontStyleKeyword`
Previously this was implemented inline within the parsing of
`{repeating}-radial-gradient()` functions but it will also be useful for
`circle()` and `ellipse()`.
We now support the CSS Images Module Level 4 additions to the
`<radial-size>` syntax, namely:
- `<length-percentage>` rather than just `<length>` for circles.
- Distinct `<radial-extent>` values for horizontal and vertical for
ellipses.
- Mixing of `<radial-extent>` and `<length-percentage>` values for
ellipses.
The regressions are due to WPT not being updated to expect the first of
these additions.
Storing these within `LengthPercentage`, `LengthBox`, and `Variant`
over-complicated things.
We also now use the correct `SerializationMode` when serializing `xywh`
and `rect`
...instead of returning the one from its associated style sheet.
This reverts 848a250b29 where I made
`CSSImportRule.media` nullable.
CSSImportRule may not have an associated style sheet, because of not
matching a supports condition, or just failing to load the URL.
Regardless of whether we do or not, the expected (non-spec) behaviour
is that we should return a MediaList always, which matches the media
queries specified on the `@import` rule.
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.
A few things fall out of this:
- We no longer need to templatize our color-stop list types.
- A bit more code is required to resolve gradient data.
This results in a slightly different rendering for a couple of the test
gradients, with a larger difference between macOS and Linux. I've
expanded the fuzziness factor to cover for it.
This works by generating random values using XorShift128PlusRNG at
compute time and then caching them on the document using the relevant
random-caching-key
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.
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.
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.
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
