Should we really have LCH coords directly on Color instances?

[LeaVerou]

Right now color.lightness, color.chroma and color.hue are shortcuts to color.lch.lightness, color.lch.chroma, and color.lch.hue. After #144 these will become color.l, color.c, color.h being shortcuts for color.lch.l etc. As I'm working on #144 and #112, I wonder: should we really have these shortcuts? We are moving away from LCH being the gold standard for these kinds of manipulations (OKLCH is now considered better). Once we release Color.js, we will never be able to change the color space of these, especially not to something as incompatible as OKLCH (which has completely different ranges).

So perhaps we should not have these at all?

[svgeesus]

Well we can change them, as can regular users, because

Object.assign(Color, {
	deltaE,
	util,
	hooks,
	WHITES,
	Space: ColorSpace,
	spaces: ColorSpace.registry,

	// These will be available as getters and setters on EVERY color instance.
	// They refer to LCH by default, but can be set to anything
	// and you can add more by calling Color.defineShortcut()
	shortcuts: {
		"l": "lch.l",
		"c": "lch.c",
		"h": "lch.h",
	},

	// Global defaults one may want to configure
	defaults: {
		gamutMapping: "lch.c",
		precision: 5,
		deltaE: "76", // Default deltaE method
		fallbackSpaces: ["p3", "srgb"]
	}
});

but yes, it is arguable whether we should have those default shortcuts at all.

[svgeesus]

Also (as we just discussed irl) these sort of customizable defaults make for hard to maintain, hard to share code.

[LeaVerou]

Ok, RESOLVED then. Man, it will feel good to get rid of all this code.