👋 After a couple years of working on this library in the background (late 2021), several notable events have happened that don’t make this worth maintaining for me:

oklab() / oklch() landed in all browsers

This is now supported in CSS in all major browsers (~86% as of Jul 2023) 🎉. There’s no JS tool that compete with a built-in CSS feature. Why use an npm package for something the web platform gives you for free?

color-mix() landed AND supports Oklab mixing

Mixing colors through Oklab via color-mix() is now supported in CSS in all major browsers, and is safe to use in web projects today.

Culori also got Oklab support

Culori added Oklab/Oklch support, and if you use the “tree-shakeable” version of colori/fn, you can basically get the footprint of better-color-tools at only a few kB gzip, but with a more stable library and support for more options.

Oh, and did I mention culori/fn is a whopping 5-10× faster than this library for the same package size? 🚀🚀🚀

  culori - test/better.bench.ts > rgb -> hex
    6.69x faster than better

  culori - test/better.bench.ts > rgb -> p3
    4.97x faster than better

  culori - test/better.bench.ts > hsl -> rgb
    8.45x faster than better

  culori - test/better.bench.ts > rgb -> oklab
    6.21x faster than better

  culori - test/better.bench.ts > rgb -> oklch
    5.98x faster than better

  culori - test/better.bench.ts > parse speed: hex string
    10.30x faster than better

Frankly, I don’t have the resources to try and tune better-color-tools to be that fast.

All of the above are developments I have welcomed, and couldn’t be happier for 🙂. But it’s made maintaining this library not worth the effort.

Though I considered the possibility of this library simply wrapping culori/fn, I’m not going to do that. Because creating unnecessary abstractions don’t make a good npm package.

Thanks to all those who tried this library and liked the API. But migrating to culori/fn for all your color needs will not only yield a better experience; you’ll also be contributing to better color science tools. And in the end, that’s what matters. 🎨

Hi !

First of all, awesome library it does exactly what I need and it's very lightweight.

But I found some issues and results quite different from https://oklch.evilmartians.io/ when using better.from(oklchString).rgb

For example:

Black:

oklch(0% 0.08567819015077803 221.11457081307586/1)

Returns: rgb(0, 0, 3)
Should be: rgb(0, 0, 0) link

oklch(0% 2.248544052636656e-8 89.8755635095349/1)

Returns: rgb(255, 0, 38)
Should be: rgb(0, 0, 0) link

White:

oklch(100% 0.12801375474374593 168.89572110316647)

Returns: rgb(159, 255, 240)
Should be: rgb(255, 255, 255) link

Other:

oklch(85% 0.17463268857418898 54.10799672454288)

Returns: rgb(255, 170, 80)
Should be: rgb(255, 189.4, 146.73) link

Anyway,

Thank you so much for this library, it saved me quite some time !

Readme states:

// Other JS formats
...
better.from({ l: 0.4856949, a: -0.03971, b: -0.14459, alpha: 1 }); // Oklab object (not CIELAB)

However, from() does not accept objects. All color types are either a string or a tuple

export type HSL = [number, number, number, number];
export type HWB = [number, number, number, number];
export type LAB = [number, number, number, number];
export type LCH = [number, number, number, number];
export type LUV = [number, number, number, number];
export type LMS = [number, number, number, number];
export type LinearRGBD65 = [number, number, number, number];
export type Oklab = [number, number, number, number];
export type Oklch = [number, number, number, number];
export type sRGB = [number, number, number, number];
export type XYZ = [number, number, number, number];
export type Color = string | number | sRGB | LinearRGBD65 | LMS | Oklab | Oklch;

and passing an oklch value is interpteted as sRGB.

Can we support HCT in Google Material design 3?

See:

1. The Science of Color & Design, from Google Material design blog
2. material-color-utilities, which implement HCT in typescipt from google

Thanks for the awesome library. Having a very pragmatic approach combined with a nice to use API: congrats!

Unfortunately there is one issue I experienced when working with "deeper" colors e.g.

oklch(76.28% 0.18 82.0399)

This is outside of the sRGB spectrum. The library seems fine for a starting point for doing calculations on sRGB values but I wish there would be an option to keep an extended color format internally and only fallback to sRGB if required e.g. by calling the methods on the from return object.

This is a nice color picker showing how it might be done better: https://oklch.com/#76.28,0.18,82.0399,100 - doing all processing on the extended color space and showing a fallback value where needed.

Long term, APCA should probably replace WCAG2 contrast calculation entirely. But with WCAG3 still being a draft (and WCAG2 being enshrined in law in many places), it might be more practical to provide them both for a time.