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.
This applies size, inline-size, and style containment in some cases.
There are other WPT tests for that, but we seem to not implement enough
of containment for this to have an effect so I've not imported those.
Gets us 35 WPT subtests.
This introduces the `TextUnderlinePositionStyleValue` class, it is
possible to represent `text-underline-position` as a `StyleValueList`
but would have required ugly workarounds for either serialization or in
`ComputedProperties::text_underline_position`
Continues the work started in #5386 to simplify handling of positional
value list shorthand properties.
Previously we would parse these as `StyleValueList`s and then rely on
`StyleComputer::for_each_property_expanding_shorthands` to expand them
into longhands.
This required a bit of work to handle `ShorthandStyleValue`s for the
`@page` `margin` descriptor.
The spec is a bit awkward here: A few algorithms create an "empty"
SourceSet, and then assign its source-size value a few steps later, so
we have a temporary state with no length. In order to avoid complicating
the types with Optional, I've chosen to just assign it to 0px.
Previously we used `auto`, but `auto` is not a valid value here - it is
used inside the "parse a sizes attribute" algorithm, but that always
returns an actual length (or calc).
Reifying the result gets quite ad-hoc. Firstly because "parse a
component value" produces a ComponentValue, not a full StyleValue like
we need for math functions. And second, because not all math functions
can be reified as a CSSNumericValue:
Besides the fact that I haven't implemented CalculatedStyleValue
reification at all yet, there are a lot of math functions with no
corresponding CSSMathValue in the spec yet. If the calculation tree
contains any of those, the best we can do is reify as a CSSStyleValue,
and that isn't a valid return value from CSSNumericValue.parse(). So, I
made us throw a SyntaxError in those cases. This seems to match
Chrome's behaviour. Spec issue:
https://github.com/w3c/css-houdini-drafts/issues/1090
This property provides a hint to the rendering engine about properties
that are likely to change in the near future, allowing for early
optimizations to be applied.
This reverts 0e3487b9ab.
Back when I made that change, I thought we could make our StyleValue
classes match the typed-om definitions directly. However, they have
different requirements. Typed-om types need to be mutable and GCed,
whereas StyleValues are immutable and ideally wouldn't require a JS VM.
While I was already making such a cataclysmic change, I've moved it into
the StyleValues directory, because it *not* being there has bothered me
for a long time. 😅
- Omit calcs that are resolved to `0px` from the serialized value
- Allow CSV to be the 'Z' component in interpolated value.
- Allow calcs with mixed percentages in the first two arguments.
To achieve the third item above the concept of a "special" value parsing
context has been added - this will also be useful for instance for
different arguments of color functions having different contexts.
Gains us 23 WPT tests
This commit regresses a couple tests related to the mask shorthand
property. This is because we now parse the longhands but there are
errors related to serialization. Some of the failures are fixed again in
the next commit. However, for some animation tests this is not the case.
Those failures were simply masked by the fact that we did not parse the
property correctly.
These will be used for the mask-repeat property as well in an upcoming
commit, hence the more generic names. Also, this more closely matches
the names used in the spec.
This parses `anchor-size(..)` functions in CSS, but does not yet result
in a useful `Size`: we need style & layout interleaving similar to
container queries for this, since the resulting value depends on layout
results.
Not supported yet: `anchor-size()` appearing inside a `calc()` node.
Adds 4280 WPT subtest passes in `css/css-anchor-position`.
"Arbitrary substitution functions" are a family of functions that
includes var() and attr(). All of them resolve to an arbitrary set of
component values that are not known at parse-time, so they have to be
substituted at computed-value time.
Besides it being nice to follow the spec closely, this means we'll be
able to implement the others (such as `if()` and `inherit()`) more
easily.
The main omission here is the new "spread syntax", which can be
implemented in the future.
This has an extra parameter to allow stopping at the first comma token,
which we need for var() and attr()'s "argument grammar".
Co-authored-by: Tim Ledbetter <tim.ledbetter@ladybird.org>
Custom properties are required to produce a computed value just like
regular properties. The computed value is defined in the spec as
"specified value with variables substituted, or the guaranteed-invalid
value", though in reality all arbitrary substitution functions should be
substituted, not just `var()`.
To support this, we parse the CSS-wide keywords normally in custom
properties, instead of ignoring them. We don't yet handle all of them
properly, and because that will require us to cascade them like regular
properties. This is just enough to prevent regressions when implementing
ASFs.
Our output in this new test is not quite correct, because of the awkward
way we handle whitespace in property values - so it has 3 spaces in the
middle instead of 1, until that's fixed.
It's possible this computed-value production should go in
cascade_custom_properties(), but I had issues with that. Hopefully once
we start cascading custom properties properly, it'll be clearer how
this should all work.
Reimplements `grid`, `grid-template`, `grid-template-rows`, and
`grid-template-columns` in a way that uses a separate function for each
grammar rule defined in the specification. This change results in many
additional passing tests from the already imported WPT suite. Most of
the remaining test failures are related to incorrect serialization of
grid properties.
