drwpow / better-color-tools

Better color tools for JS, TS, and Sass. Supports Oklab and CSS Color Module 4.

Home Page:https://better-color-tools.pages.dev/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Inaccurate readme

StarLederer opened this issue · comments

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.

It should accept an object; these tests even sure that’s still working right now.

I believe maybe there’s just confusion around the types—those are output types, not input types. In your example, if you called better.from(…).oklabVal you would indeed get a [number, number, number, number] type ([0.4856949, -0.03971, -0.14459, 1]) which matches (note: worth noting that this library will “snap” values to the closest sRGB color, so it’s intentionally lossy, in case you are ever returned a different value it just calculated the nearest-displayable color since Oklab’s range is boundless).

However, if you then tried and take that 4-length array and pass it back into better.from(), that’s where it would err because it’s just an array—it has no clue what colorspace that is. And so better.from() only accepts sRGB arrays as input, hence the object format.

Additional Info

The reason for returning an array for all colorspaces for better.from(…).*Val is more an implementation detail. When converting between colorspaces you use color matrixes that have an ordering to them, and they have to be converted to arrays anyway to preserve that ordering. And ordering also matters in CSS color functions (e.g. when using rgb(…) you can’t rearrange the channels). But again, an array gives no hints as to what colorspace it is, hence the object input differing here.

Unless I’m misunderstanding I don’t think there’s an issue with the README? Perhaps just the exported types aren’t what you expected?

It should accept an object;
better.from() only accepts sRGB arrays as input

There is definitely a misunderstanding somewhere because i see these sentences as contradictory.

I believe maybe there’s just confusion around the types—those are output types, not input types

I am pretty sure those are input types and ColorOutput is the output type.

// parse.ts
export function from(rawColor: Color): ColorOutput {
  // ...
}

I don't know if this actually works at runtime but type checker is not happy with me providing it an object.

Thanks for clarifying. I was able to push a better update to the types, and also converted the tests to TypeScript to prevent this from happening again. Please try the latest version and let me know if you have any additional problems 🙏