mattdesl
commented
4 weeks ago Hey @limzykenneth thanks for considering this library!
Some notes:
@texel/color, unlike other libraries like Colorjs and culori, is different in that it doesn't try to match CSS spec exactly (but takes inspiration from it in terms of color space choices and conversion matrices). This will allow the library to remain fairly stable for many years, even if CSS Color spec continues to expand in complexity. So if matching CSS spec is really important, it might not be worth using@texel/colorfor anything except very hot code paths (such as per-pixel manipulation).- I hadn't planned on supporting CIELab as it's basically made obsolete by OKLab (and OKLCH), but if there is a reason to support it, it shouldn't be too difficult to add.
- Yes, this is something that should already work, however is not documented. I can try to show an example of this.
- Colorjs.io interpolation is based on CSS spec, including some things like allowing flexibility to choose "longest" or "shortest" arcs through circular hue interpolations, which I'm not really sure how useful is in practice. Linear interpolation is already supported by
@texel/color(although not well documented), and circular interpolation should be easy to add (already present in the source, but commented out), so the next question becomes what other features would be important for color interpolation? - In general, I am open to adding new features to this library so long as (1) they don't impact the current bundle size or performance, (2) they don't introduce significant maintenance headaches over time.
- At the moment I don't have any interest in matching CSS color strings in this library; the complexity feels high, and it's a moving target that will likely continue to grow in scope over the years, requiring constant maintenance. I think the best option would be to use another library specifically for the CSS color strings. It should be pretty easy to have that work alongside
@texel/color, even for example css-color parser works fine for some spaces right now, but it does not match 100% of the color string spec either. Things likecalc()and relative colors will be tedious to parse.
I'll see what I can do about adding additional documentation and examples for your needs.
Hi, this library was pointed out to me while I am looking into rewriting the color modules of p5.js which the initial plan is to use color.js as a backing dependency, however what you have implemented here is really exciting and I am looking into using this instead of color.js.
There are several things that we need for p5.js that are not currently supported and I would like to know what your thoughts are in terms of implementing them in @texel/color, whether they are not planned to be supported or something that @texel/color would like to have. I may have some misunderstanding around colors so do point out if anything don't make sense here.
lab()andlch()functions are both in CIE color space which we like to support if possible. If the intention is to not support CIE colors at all then it leads to the next item.rgb(0, 128, 255)andrgb(0 128 255)are valid and supported CSS strings but only the former works, color words such asgreenalso does not work, alpha deserialization also does not work; for serialization,hslseems to be serialized into acolor(okhsl)string instead which have less support in CSS than the nativehsl()function.Depending on what the plan for this project is, p5.js can possibly help with providing some implementation support to implement some of the above since if we were to use @texel/color as the backing dependency of our color module, we will need to implement them anyway so I feel it's much better to do it here instead.
Really look forward to see what comes for the rest of the project!