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
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 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.
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.
For whatever reason, this method in particular ends up failing to link
into WebContent with a subsequent change. It's small and simple, so
just inline it.
As it turns out, SkPath already behaves the way we need for SVG and HTML
canvas elements. Less work for us, yay! This removes a 5% item from the
profile when scrolling on https://imdb.com/
Note that there's a tiny screenshot test expectation change due to
minor antialiasing differences when we no longer do our redundant
subpath modifications.
We have a slightly odd setup here. TransformationStyleValue reifies as a
single CSSTransformComponent. It's StyleValueList that actually reifies
as a CSSTransformValue - but only if it only contains
TransformationStyleValues.
+79 WPT subtests.
We now:
- Serialize longhands in the correct order
- Support serializing multiple values
- Include default longhands where required (to distinguish
animation-name from that longhand).
Previously we would clamp the percentage value to the allowed range for
canonical dimension values rather than the percentage value.
Also fixes an issue where we would clamp pure percentages (i.e.
percentages that don't have a hint) against the allowed values for the
first dimension we checked (i.e. angle)
