Avoid implied color space dependencies for procedural usage

[aduth]

Updates utility functions to use color space objects directly rather than retrieving the color space by a string lookup, which infers a dependency that those color spaces are already registered.

This improves usability of the procedural API. Currently, if someone opts-in to the procedural API and wants to use these utilities, the consumer has to ensure that the color space is registered, which is not obvious.

Using the color space object directly ensures these functions are independently self-contained and don't have any implied dependencies.

I noticed similar implied dependencies in lighten and darken functions, but given the "alternatives" fallbacks used there, it's less clear to me how best to handle those color spaces. I'm happy to update those functions as well if there's a direction that makes sense.

[netlify]

✅ Deploy Preview for colorjs ready!

Name	Link
🔨 Latest commit	3355ecf
🔍 Latest deploy log	https://app.netlify.com/projects/colorjs/deploys/6a05df92b82a9200087bfc3f
😎 Deploy Preview	https://deploy-preview-734--colorjs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[LeaVerou]

Totally unrelated to this PR, but we shouldn't be having colorspace-specific stuff in a generic function like this. Especially for non-essential color spaces. This should live together with the HCT color space!

[LeaVerou]

I need to look more closely but it seems that the oklch space is only used in the toGamutCSS() path? If so, this makes tree shaking worse, since it essentially turns a peer dependency that is rarely needed into a regular dependency.

It's probably not a huge deal since most people do need oklch, and it's pretty small but thought I'd flag it and see what others think.

That said, I'm not even sure we should have toGamutCSS() in core. CSS itself is moving away from this! We should probably move the whole thing to a plugin…

[aduth]

If my read of the code is accurate, toGamutCSS would be the default path for all toGamut usage unless method is overridden to something other than 'css' (gamut_mapping defaults to 'css' which toGamut directs to toGamutCSS)?

[lloydk]

I need to look more closely but it seems that the oklch space is only used in the toGamutCSS() path? If so, this makes tree shaking worse, since it essentially turns a peer dependency that is rarely needed into a regular dependency.

It's probably not a huge deal since most people do need oklch, and it's pretty small but thought I'd flag it and see what others think.

toGamutRayTrace() also uses oklch.

That said, I'm not even sure we should have toGamutCSS() in core. CSS itself is moving away from this! We should probably move the whole thing to a plugin…

I would like to see some kind of plugin system so that all of the gamut mapping methods aren't in a single file and additional gamut mapping methods could be added e.g. https://bottosson.github.io/posts/gamutclipping/

[lloydk]

I haven't looked that closely but couldn't this PR be as simple as:

• import oklchSpace from "./spaces/oklch.js";
• delete the calls to ColorSpace.get("oklch")

[facelessuser]

I generally agree that as the gamut mapping options grow, making gamut mapping methods into plugins probably makes more sense, though that is tangential to this PR.