Closed surma closed 3 years ago
The sample code is intended primarily to be straightforwardly read (by humans), as explanation. The fact that it also works is an added bonus.
In terms of usability though, the simple procedural style means that the user needs to know exactly what they are doing. As an example, to convert a prophoto-rgb
color to display-p3
you would do all the steps yourself, in the right order: convert from gamma-encoded to linear-light, convert that to XYZ, do the chromatic adaptation from the prophoto-rgb
whitepoint of D50 to the display-p3
whitepoint of D65, convert those XYZ values to linear-light display-p3
, then apply the gamma encoding.
let color1 = [0.54, 0.928, 0.305];
let color2 = gam_P3(XYZ_to_lin_P3(D50_to_D65(lin_ProPhoto_to_XYZ(lin_ProPhoto(color1)))));
// [0.457, 0.986, 0.299]
So in addition to using ESM it would be better to use code which is object oriented and does the right thing automatically. @leaverou and I took the logic from the sample code and did exactly that to create color.js
Here is the same example in color.js:
let color1 = new Color("color(prophoto 0.54 0.928 0.305)");
let color2 = color1.to("p3");
// color(display-p3 0.457 0.986 0.299)
color.js can be used in Node, or in a browser (and does not depend on browser support for any of CSS Color 4). The API has extensive documentation which can be live-edited to try things out, and a color notebook for experimentation (some editing bugs, but still useful). We also made a handy conversion app. The downside of all that, is that the JS source is longer, and somewhat harder to read due to error-checking and extensibility hooks.
It is all on GitHub and to use it simply
import Color from "https://colorjs.io/dist/color.esm.js";
I would also like to draw your attention to the Color API which is being incubated in WICG and is intended to be a web platform color API. Drawing on the experience with color.js and with CSS typed OM, it should be a lean, cut-down API that correctly does all the common things authors would need.
Yeah saw the Color API and quite excited about it.
This makes a lot of sense to me. Thanks for taking the time to clarify :) Closing this.
I was delighted to find that the css-color-4 directory contains JavaScript code to do all kinds of color space conversions. I think this is really helpful for experimentation.
The current JavaScript files are supposed to be included via
<script>
tags and will register functions on the global scope. Additionally, the dependencies between the JavaScript files are documented as comments (like// needs conversions.js
inutilities.js
).Is there anything speaking against moving these JavaScript files to ESM? All browsers support those and it’s the de-facto standard to author in ESM nowadays which is also arguably the best-supported format in bundlers, so it would make these files more useful outside this repository. It also would make the dependencies between files explicit.
I’m happy to put in the work, just wanted to check first.