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.
