When we originally implemented calc(), the result of a calculation was
guaranteed to be a single CSS type like a Length or Angle. However, CSS
Values 4 now allows more complex type arithmetic, which is represented
by the CSSNumericType class. Using that directly makes us more correct,
and allows us to remove a large amount of now ad-hoc code.
Unfortunately this is a large commit but the changes it makes are
interconnected enough that doing one at a time causes test
regressions.
In no particular order:
- Update our "determine the type of a calculation" code to match the
newest spec, which sets percent hints in a couple more cases. (One of
these we're skipping for now, I think it fails because of the FIXMEs
in CSSNumericType::matches_foo().)
- Make the generated math-function-parsing code aware of the difference
between arguments being the same type, and being "consistent" types,
for each function. Otherwise those extra percent hints would cause
them to fail validation incorrectly.
- Use the CSSNumericType as the type for the CalculationResult.
- Calculate and assign each math function's type in its constructor,
instead of calculating it repeatedly on-demand.
The `CalculationNode::resolved_type()` method is now entirely unused and
has been removed.
This reverts commit 76daba3069.
We're going to need separate types for the JS-exposed style values, so
it doesn't make sense for us to match their names with our internal
types.
CSS filters work similarly to canvas filters, so it makes sense to have
Gfx::Filter that can be used by both libraries in an analogous way
as Gfx::Color.
Previously we created a tree of CalculationNodes with dummy
UnparsedCalculationNode children, and then swapped those with the real
children. This matched the spec closely but had the unfortunate
downside that CalculationNodes couldn't be immutable, and couldn't know
their properties at construct-time. UnparsedCalculationNode is also a
footgun, as if it gets left in the tree accidentally we would VERIFY().
So instead, let's parse the calc() tree into an intermediate format, and
then convert each node in that tree, depth-first, into its
corresponding CalculationNode. This means each CalculationNode knows
what its children are when it is constructed, and they never change.
Apart from deleting UnparsedCalculationNode, we can also get rid of the
for_each_child_node() method that was only used by this "replace the
children" code.
With all the plumbing in place, we can handle this quirk at the
serialization layer.
This allows us to remove the pass where StyleComputer would loop over
all computed values and replace any color values with new values
stripped of their original name strings.
Fixes the crash in css/css-color/parsing/color-valid-hwb.html.
The crash was probably introduced in 248e4bb5, as it was the first
commit to VERIFY that the value given to `Color::with_opacity` were in
the correct range. As the values in color-valid-hwb.html were resolved
as NaN, the check never passed.
The length resolution context might be needed even when resolving an
integer value, since it might contain a sign() function with length
values inside. This fixes a WPT subtest.
Regardless of what the shorthand property is, if all its longhands are
the same CSS-wide keyword such as "initial" or "inherit", then it's the
same as the shorthand being that value.
This gets us 2 WPT subtest passes.
When serializing an sRGB color value that originated from a named color,
it should return the color name converted to ASCII lowercase. This
requires storing the color name (if it has one).
This change also requires explicitly removing the color names when
computing style, because computed color values do not retain their name.
It also requires removing a caching optimization in create_from_color(),
because adding the name means that the cached value might be wrong.
This fixes some WPT subtests, and also required updating some of our own
tests.
See previous the commit description for more details about the floating
points operations.
The hwb test cases in `css-color-functions` are now rendered identically
to what firefox does (I haven't checked the others tests, but they
aren't affected by this commit).
Without this change the math in `CSSHWB::to_color()` is lacking some
precision to generate the correct value to hand to `Color::from_hsv()`.
More precisely, when converting `hwb(120 20 30)`, the HSV's value would
be calculated as `1 - .3`. However, it turns out that `1 - .3f != .7f`
and `1 - .3f` gives bad results down the road in `Color::from_hsv()`.
This example actually only requires `resolve_with_reference_value()` to
return a double. I changed the two others for symmetry.
This color space is often used as a reference in WPT tests, having
support for it makes us pass 15 new tests:
- css/css-color/rec2020-001.html
- css/css-color/rec2020-002.html
- css/css-color/rec2020-003.html
- css/css-color/rec2020-004.html
- css/css-color/rec2020-005.html
- css/css-color/predefined-011.html
- css/css-color/predefined-012.html
That makes us pass the following WPT tests:
- css/css-color/prophoto-rgb-001.html
- css/css-color/prophoto-rgb-002.html
- css/css-color/prophoto-rgb-003.html
- css/css-color/prophoto-rgb-004.html
- css/css-color/prophoto-rgb-005.html
- css/css-color/predefined-009.html
- css/css-color/predefined-010.html
This color space is often used as a reference in WPT tests, having
support for it makes us pass 15 new tests:
- css/css-color/display-p3-001.html
- css/css-color/display-p3-002.html
- css/css-color/display-p3-003.html
- css/css-color/display-p3-004.html
- css/css-color/display-p3-005.html
- css/css-color/display-p3-006.html
- css/css-color/lab-008.html
- css/css-color/lch-008.html
- css/css-color/oklab-008.html
- css/css-color/oklch-008.html
- css/css-color/predefined-005.html
- css/css-color/predefined-006.html
- css/css-color/xyz-005.html
- css/css-color/xyz-d50-005.html
- css/css-color/xyz-d65-005.html
This makes us pass the following WPT tests:
- css/css-color/a98rgb-001.html
- css/css-color/a98rgb-002.html
- css/css-color/a98rgb-003.html
- css/css-color/a98rgb-004.html
- css/css-color/predefined-007.html
- css/css-color/predefined-008.html
That makes us pass the following WPT tests:
- css/css-color/srgb-linear-001.html
- css/css-color/srgb-linear-002.html
- css/css-color/srgb-linear-003.html
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
This was a silly mistake on my end and percentages values are not
covered by device-independent color space, so I had to add support for
srgb to run a WPT test that made me realize the mistake.
This makes the following test pass:
- css/css-color/predefined-002.html
It makes the following WPT tests pass:
- css/css-color/predefined-001.html
- css/css-color/xyz-003.html
- css/css-color/xyz-d50-003.html
- css/css-color/xyz-d50-004.html
- css/css-color/xyz-d65-003.html
Also we now render the reference of color-mix-currentcolor-nested-for-
color-property.html properly. Which means that it's now different from
the actual test, that is still rendered incorrectly. In other word, the
false positive for this test is now turned into a true negative.
