[css-houdini-drafts] [css-typed-om] Possible features for CSSColorValue (#1040)

tabatkins has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== [css-typed-om] Possible features for CSSColorValue ==
In <https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-841203333>, Lea gave the following list of features potentially missing from Typed OM's color classes, that would be useful in a dedicated color class:

> * Provide conversion between color spaces
> * 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.
> * A way to check whether the color is in gamut of the current color space or another color space
> * Parsing and serialization
> * Relative and absolute color manipulation by tweaking coordinates in arbitrary color spaces, ideally without having to manually convert to these spaces and back.
> * 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).
> * Interpolation and color mixing are needed in a large number of use cases (visualizations, palette generation, gradients etc)
> * Compositing & blending
> * Contrast calculation
> * 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).
> * 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.



Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1040 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:17:01 UTC