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.
Tree counting functions should be resolved at style computation time -
to do this we will need to know the element's sibling count and index.
This commit computes that information and propagates it to the various
`StyleValue::to_computed_value` methods.
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
Before this change we would maintain explicit signs when serializing
e.g. `animation-iteration-count: calc(+1)` would serialize as `calc(+1)`
rather than `calc(1)` as intended
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
In some cases a document may lack an associated window - to fix this for
now we just return false but perhaps there are some media queries we
should still attempt to resolve.
Previously these were only stored on the root style sheet and were
accessed by imported stylesheets via their owner rule.
Propagating these to imported style sheets allows us to more easily know
when they change for said imported style sheets.
Some documents (e.g. those created by DOMParser.parseFromString()) will
not be associated with a navigable. These documents effectively have a
viewport of 0x0.
CSSTransformComponents hold other CSSStyleValues as their parameters. We
want to be able to create internal representations from those parameters
without them caring if they would be valid when directly assigned to the
property.
This is a temporary solution to make transform functions work. To be
completely correct, we need to know what is allowed in that context,
along with value ranges - a combination of the contexts we create when
parsing, and when computing calculations. For transform functions, this
doesn't matter, as there's no limit to the range of allowed values.
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.
create_numeric_value() will be used next to create a CalculationNode,
and I didn't want to have to duplicate the "create a value based on the
unit name" code.
No behaviour change.
We have this code duplicated in multiple places, and we'll want to
handle registered custom properties too at some point, so wrap it in a
reusable `CalculationContext::for_property()` method.
Noticed while doing this that ValueParsingContext will eventually need
to take a PropertyNameAndID, not a PropertyID, so I've added a FIXME.
Adds pinch event handling that adjusts the VisualViewport scale and
offset. VisualViewport's (offset, scale) is then used to construct a
transformation matrix which is applied before display list execution.
Implements spec algorithm for viewport scrolling that first checks if
it's possible to use delta to move the visual viewport before falling
back to scrolling the layout viewport. This is a part of pinch-to-zoom
support.
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.
As noted in the linked spec issue, it's possible for an author to
construct a CSSUnparsedValue that contains itself, meaning
serialization would be infinitely recursive. So instead, detect that
and then return an empty string, which copies Blink's solution to this
issue.
Stops `css/css-typed-om/cycle-in-unparsed-value-crash.html` from
crashing after we implement converting a CSSUnparsedValue to an
UnresolvedStyleValue, as that relies on serialization.
