Doing trigonometric calculations with floating point numbers can
introduce small inaccuracies. This meant that we would sometimes
incorrectly generate a 3d rather than 2d matrix for the resolved value
of `transform`.
Gains us 3 WPT 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.
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
Canonicalization can require information that is only known after
compute time (i.e. resolved relative lengths within calcs).
This also allows us to get rid of the `had_explicit_input` flag and just
rely on whether Optional has a value
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.
Because we store calculations as a tree of CalculationNodes inside a
CalculatedStyleValue, instead of a tree of StyleValues directly, this
implements a create_calculation_node() method on CSSNumericValue.
CSSMathValue::create_an_internal_representation() then calls
create_calculation_node() on itself, and wraps it in a
CalculatedStyleValue.
Lots of WPT passes again! Some regressions, which are expected: `cursor`
fails a test for the same reason it fails other that set it to some
kind of numeric value: We don't distinguish between "can contain a
number" and "can accept a number by itself". This will affect any
similar properties, but overall this is a big improvement.
Shorthands should be broken up into their longhands, instead of setting
them directly.
There's a catch here with our "positional value list shorthands" like
`margin`: Setting margin to a single value like `CSSUnitValue(10, "px")`
is supposed to fail here, but our type-checking code thinks it's valid
because our JSON for `margin` says it accepts lengths. This is the same
kind of issue that we had for `cursor` discussed in the
"LibWeb/CSS: Support converting CSSUnitValue to a StyleValue" commit.
Will get us a few subtest passes for every shorthand that's tested.
Unfortunately this doesn't pass a lot of tests, because we strip out
whitespace when parsing property values. In particular, the WPT suite
tests with this:
```js
new CSSUnparsedValue([' ', new CSSVariableReferenceValue('--A')])
```
...which gets the whitespace stripped from the string, meaning when we
convert the value back to JS, we get the equivalent of this:
```js
new CSSUnparsedValue(['', new CSSVariableReferenceValue('--A')])
```
...and that's not the same so the test fails.
A lone CSSUnitValue can now be converted to a dimension StyleValue of
the relevant type, as long as the property allows that type. If the
value is out of the allowed range, it's wrapped in calc().
There are a few failing tests still, involving setting a negative
percentage and expecting to read the computed value as 0. Those also
fail in Chromium, and a similar negative-length test expects a negative
computed value (not 0), so this appears to be an incorrect test.
Also, we regress some of the `cursor` tests. This is because our "does
property X accept type Y?" code is too naive: `cursor` is defined to
accept "number [-∞,∞]" in the JSON, and that value range is used when
clamping the result of calculations or interpolation. But because that
entry is there, we think a single number is a valid value for `cursor`.
Solving this generally is a larger task than I want to take on right
now. :^)
