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)
We shouldn't include spread distance when serializing `text-shadow` as
it is not supported unlike `box-shadow` - to achieve this we store
whether this is a text or box shadow within the ShadowStyleValue and
serialize appropriately.
