- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Fri, 14 May 2021 12:08:49 +0000
- To: public-houdini-archive@w3.org
@tabatkins So all the changes you can think of are about syntax, not functionality?! No wonder you think this would be sufficient (though having to deal with objects instead of numbers would be **really** painful, think of how bad the SVG DOM is — and that wasn't even on my radar!) Off the top of my head (and based on my work and research on this with @svgeesus for the last year or so), I think that to cater to most author use cases, a color object for the Web would need to at least: - 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) - 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. J<sub>z</sub>a<sub>z</sub>b<sub>z</sub> 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. I honestly don't think it would be a good idea to hang all of that off of a Typed OM object, nor are they in scope for what the Typed OM does. And especially now that you pointed out this issue with dealing with numbers, I'm even more convinced this is a bad idea that will lead to a lot more developer pain than just having to do `new Color(csscolorvalue)` or `csscolorvalue.toColor()` or whatever. What do you mean by "magic tear-offs"? @annevk The difference needs to be preserved for Typed OM, since it's preserved for serialization. Not to mention that `color(srgb)` and `rgb()` are treated differently in CSS. The former is 10 bit whereas the latter is 8 bit, and the former uses the new improved interpolation, whereas the latter is legacy and uses legacy interpolation. The reason you think they should both be represented by the same object (which one though? `CSSRGB` or `CSSColor`?) is exactly because you are trying to make this into something it is not, just to avoid having two color objects (even though their purposes and use cases are entirely different). But by trying to combine them, all that will be achieved is one object that does neither job well… -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-841203333 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 12:08:51 UTC