Returning this struct will allow us to modify the underlying value of
the `CalculationResult` without requiring us to go through the process
of constructing a whole new `CalculationResult` to return.
This currently only applies to property-level calculation contexts, more
work to be done to generate accepted ranges for other calculation
contexts (e.g. within transformation functions, color functions, etc)
When converting rotate transform functions `sin` and `cos` can sometimes
be inaccurate. To avoid these inaccuracies we:
- Mod the angle to minimise inaccuracies in the first place.
- Discard tiny (smaller than epsilon) values returned by `sin` and
`cos` as inaccuracies.
This is in line with other browsers (e.g. Gecko and WebKit).
CSSUnitValue is a typed-om type which we will implement separately in
the future. However, it still seems useful to give our dimension values
a base class. (Maybe they could be templated in the future?) So instead
of deleting it entirely, rename it to DimensionStyleValue and make its
API match our style better.
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
Technically, env() should not be an ASF. (😱) This is why some tests
still fail - env() as specced is expected to have its syntax checked
fully at parse-time, whereas ASFs are not properly syntax-checked until
later. However, I think this approach was worth doing for a few reasons:
- env() behaves like an ASF otherwise. (It is replaced with a set of
arbitrary component-values that are not known until computed-value
time.)
- env() was defined before the ASF concept existed, so I strongly
suspect it will be updated in the future to match that definition,
with a couple of adjustments. (eg, env() is allowed in some extra
places compared to var() and attr().)
- This was much quicker and easier to implement (under 3 hours in total)
compared to the greater amount of work to implement a whole separate
system just for env().
- Most of these tests are marked tentative, and the spec definition of
env() is still somewhat in flux, so failing some is not a huge deal.
If in the future I turn out to be wrong on this, we can convert it to
its own special thing.
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.
