Support CSS Color Module Level 4
liZe opened this issue · 9 comments
(Current code is in the color4 branch.)
The primary change, compared to CSS Color 3, is that CSS colors are no longer restricted to the narrow gamut of sRGB.
To support this, several brand new features have been added:
- predefined, wide color gamut RGB color spaces with the
color()function - lab(), lch(), oklab() and oklch() functions, for device-independent color
Other technical changes:
- Serialization of
<color>is now specified here, rather than in the CSS Object Model - hwb() function, for specifying sRGB colors in the HWB notation.
- Addition of named color rebeccapurple.
In addition, there have been some syntactic changes:
- rgb() and rgba() functions now accept
<number>rather than<integer>. - hsl() and hsla() functions now accept
<angle>as well as<number>for hues. - rgb() and rgba(), and hsl() and hsla() are now aliases of each other (all of them have an optional alpha).
- rgb(), rgba(), hsl(), and hsla() have all gained a new syntax consisting of space-separated arguments and an optional slash-separated opacity. All the color functions use this syntax form now, in keeping with CSS’s functional-notation design principles.
- All uses of
<alpha-value>now accept<percentage>as well as<number>. - 4 and 8-digit hex colors have been added, to specify transparency.
- The none value has been added, to represent powerless components.
Kudos to @ax-sc!
The level 3 test suite passes with the color4 module 🚀. I’ll add more tests in the test suite when everything in the list above is resolved.
Note that CMYK support has been postponed to level 5 (it was already postponed from level 3 to 4).
The level 3 test suite passes with the
color4module .
Well, it doesn’t. Thanks to isort I’ve found that imports were broken. But news are still really good: the tests failing are the ones that are supposed to give different results with Level 3 and Level 4.
I’ll open a PR to split 3 and 4 in the testing suite. (Edit: CourtBouillon/css-parsing-tests#10.)
Thanks for moving this forward, @liZe. I added some test cases for the parts of the specification introduced with #48 in CourtBouillon/css-parsing-tests#11.
If you want, i can have a look at the missing lab(), lch, oklab and oklch functions but i´m not sure when i will find the time do so, so i can not promise to have them implemented at a specific date.
I added some test cases for the parts of the specification introduced with #48 in CourtBouillon/css-parsing-tests#11.
Amazing, thanks a lot!
If you want, i can have a look at the missing
lab(),lch,oklabandoklchfunctions but i´m not sure when i will find the time do so, so i can not promise to have them implemented at a specific date.
It will be probably more difficult to test, because these functions don’t directly return sRGB colors. I have to read the specification again and again to understand how "device-independent colors" work and thus how they can be tested. If you know anything about gamuts and color spaces, don’t hesitate to share your hints! It could be easier to understand than Wikipedia’s very informative but quite dense pages.
It will be probably more difficult to test, because these functions don’t directly return sRGB colors.
Yes, that´s the reason why i did not implement them in the first step.
I have to read the specification again and again to understand how "device-independent colors" work and thus how they can be tested. If you know anything about gamuts and color spaces, don’t hesitate to share your hints! It could be easier to understand than Wikipedia’s very informative but quite dense pages.
Although i know some things about color spaces etc., i would definitely need to look at the specification myself again as well. I will keep you updated and try to summarise the most important information once i have done this.
Although i know some things about color spaces etc., i would definitely need to look at the specification myself again as well. I will keep you updated and try to summarise the most important information once i have done this.
I’ve added some code to handle the missing lab and oklab functions. I hope that I’ve understood the specifications correctly, don’t hesitate to tell me what’s wrong!
Handling the none value adds an interesting complexity. And by "interesting", I mean another word.
As we sometimes convert the original value into "normalized" value (for example hsl to rgb or now lab to xyz), there’s no way to keep the information of the original unknown channels. As a low-level CSS parser, it seems important to keep this information that could be useful for example for gradients (and could become even more important in level 5 when it’s possible to extrapolate colors with CSS functions 🤯️).
Leading to this question: is the new standard Color class a good idea? It seems to be both right and quite easy to use as it is now, but it’s obviously not compatible with the none keyword.
A solution would be to keep this class to store the computed value, but add the original function in other fields. This way, we could keep the current "simple" computed fields while keeping the original fields (possibly containing none) for cases where it’s useful.
Sorry to interrupt, do you think it is safe to pip install this branch? I need hsl support.
Or is there a chance that you do a pull request before solving 100% of what you planned to do?
I need hsl support.
As explained in Kozea/CairoSVG#379, hsl is already supported in Level 3.