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.
Typed-OM means that the author can set a property's value to a
CSSUnparsedValue, which may or may not have any arbitrary substitution
functions in it. This VERIFY was just there to catch parsing bugs that
created UnresolvedStyleValues unnecessarily, and removing it is
harmless.
This avoids regressions in the next commit.
See the linked spec issue for details. Without this, we end up doing the
wrong thing in cases like this, from a WPT test:
```js
styleMap.set('transition-duration', '1s', 'var(--A)');
```
`'var(--A)'` is a string, not a CSSVariableReferenceValue or
CSSUnparsedValue. Following the spec literally, we wouldn't throw a
TypeError here, even though we really should: The purpose of the check
is for list-valued properties, to prevent authors putting a series of
tokens that would represent multiple list items, into a single list
item slot.
So, we delay the check until after we've converted strings into values.
This does mean we're checking StyleValues instead of CSSStyleValues,
and it also means we've done more work before rejecting the input as
invalid. But correctness is nice. :^)
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. :^)
Reverts c8bd58c and 0df9c22. These were used to absolutize values stored
within other `StyleValue`s but we should instead store these values as
`StyleValue`s directly instead of within `{Calculated,Percentage}Or`.
This struct will in the future hold information other than a length
resolution context (e.g. context for tree counting functions) and a
single struct is easier to work with than multiple parameters.
Pending changes to an ancestor document's layout can affect an element's
computed style e.g. an IFrame's width being changed can affect media
query evaluation and the value of the `vw` unit.
Previously we would always use the window's viewport which was incorrect
if we were within an iframe.
This is likely applicable to all uses of
`Length::ResolutionContext::for_window`.
We were using the font's point size instead of it's pixel size, we were
already computing this information earlier in the function anyway so
let's just use that.
With this commit, only direct CSSStyleValues created from internal
StyleValues can be converted back to a StyleValue. More subtests will
pass as create_an_internal_representation() is implemented for the
various CSSStyleValue subclasses. :^)
Gets us... a LOT of WPT passes, because there's a ton of coverage for
each property.
When setting style to a CSSStyleValue we need to convert it to a
StyleValue. If we already have one, we might as well use it avoid the
work of serialization and re-parsing.
I realised I misunderstood what "constructed from a USVString" means, so
I've adjusted based on that. It does raise a question on what the source
USVString is if that string resulted in multiple CSSStyleValues being
created - see the linked issue.
Typed-OM requires us to have a generic way of asking "does property X
accept a list or a single value?" so this exists mainly for that.
Coordinating lists are annotated too - I'm not clear on exactly what
will be needed for those, but giving them a unique value now at the
worst will make them easier to find later.
This commit modifies the `compute_foo()` code for `font-style` and
`math-depth`. They previously assumed that their StyleValue was always
a special kind: FontStyleStyleValue or MathDepthStyleValue. This was
always true, because that's how we parse them, but it stops being true
once StylePropertyMap is involved: An author can set font-style to a
CSSKeywordValue of "italic", and this should work.
There are multiple ways that we could solve this, but the simplest and
easiest to maintain seems to be to handle those more basic StyleValues
in this computation code. Going forward, we'll have to be aware that
similar properties could have a basic StyleValue from the typed-OM
instead of the property-specific one we'd expect.
