- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 14 May 2021 17:50:46 +0000
- To: public-houdini-archive@w3.org
> Provide conversion between color spaces ✔ Already provided by TypedOM. > Provide control over when (and how) gamut mapping occurs when converting. For many use cases you need lossless conversion so you can roundtrip, for others you need an in-gamut color. Definitely doable. Right now the to() function is just meant to invoke the algos in Color 4; it's not super clear, but I *think* it automatically gamut-maps (as written in <https://drafts.csswg.org/css-color-4/#lab-to-predefined>). Adding an option to tell it not to map sounds completely reasonable. > A way to check whether the color is in gamut of the current color space or another color space Absolutely reasonable to add, I think. > Parsing and serialization ✔ Already in. > Relative and absolute color manipulation by tweaking coordinates in arbitrary color spaces, ideally without having to manually convert to these spaces and back. ✔ Already in, tho you do need to convert explicitly to the space you want to work in. In <https://github.com/w3c/css-houdini-drafts/issues/1034> I asked for examples of where you would want to do a tweak in one space and then convert back, but I haven't gotten a response yet - Chris provided several useful examples of wanting to convert to another color space, but they're all doing something with a pair of colors that you need to put into a shared color space (which one or neither of them might be in). None of his examples showed off having a color start in one space, get tweaked in another space, then put back into the original space. As I said in #1034, we *can* definitely offer such a functionality if it's needed, and I sketched out a simple method for achieving it. I just haven't heard justification for needing it yet. > To be future-proof and extensible, it needs to be as color space agnostic as possible. It needs to be able to work with HDR and white gamut color spaces. It should not privilege sRGB or any other color space or model through special syntax, nor use generic "RGB" keywords to represent a specific RGB space (e.g. sRGB). ~Partially. Any color space CSS supports can be used (and any color space we want to support on the Web, we'll want to support in CSS, so it'll show up here), and now that I've made some tweaks to the `.colorSpace` and `.to()` methods, the API is pretty agnostic to them. The only real difference is whether they have predefined names for their channels exposed (all the CSS color spaces with built-in functions) or if you have to access the channels by index (all the color() values). None of the color spaces are otherwise privileged thru syntax, tho "rgb" does specifically refer to the CSS rgb() function, and thus the sRGB space. Given the existence of CSS colors and the rgb() function, tho, anything that *didn't* let you refer to "colors like what rgb() does" seems like it would be author-hostile, and using any name other than what the rgb() function itself uses feels like the same, especially if the other spaces all get to use their CSS function name. I think I'm happy to actively oppose this particular requirement, and would probably push back against it in a bespoke Color api for the web, too. > Interpolation and color mixing are needed in a large number of use cases (visualizations, palette generation, gradients etc) The Color 5 functions will be supported in Typed OM as soon as I'm reasonably certain they're stable in the Color spec, and just like the math functions on CSSNumericValues that let you say `num1.add(num2)` instead of `new CSSMathSum(num1, num2)`, I think convenience methods on CSSColorValue that let you mix/interpolate/etc colors makes sense. > Contrast calculation Absolutely reasonable to add, I think. > Color difference calculation (DeltaE) to be able to compare similarity between colors, ideally multiple algorithms to allow authors to make tradeoffs between efficiency and accuracy, or an API that allows extensibility (especially since many new color spaces come with their own DeltaE algorithms, e.g. Jzazbz or ICtCp). Also completely reasonable to me. Exactly what algos we expose can be debated, but having at least some is completely reasonable, since it's something I know I've used (by hand, painfully) when working with color in the past. > Extensible: Authors need to be able to register new color spaces or new color models over existing spaces. At the very least in the same way that they can add @color-profile rules in CSS, but ideally as long as they can provide conversion code to and from XYZ (or any other connection space) they shouldn't need an ICC profile. In CSS an ICC profile is the only way to register a new space because an @-rule cannot provide code, but JS doesn't have this limitation. Agreed and tracked in a generic fashion in #1038, tho the right design might end up being piecemeal specialized extensibility points. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1040#issuecomment-841405044 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 May 2021 17:50:48 UTC