Expose way to serialize and parse individual coords and alpha

[kleinfreund]

TL;DR: Expose ways to

• serialize color coords/alpha
• parse strings representing individual coords/alpha

Current status

Currently, one can already serialize individual coords with the help of Format and Type:

Demonstration using some extra code to configure the preferred CSS type per coord (e.g. <number> for RGB)

(function () {
	const preferredTypesBySpace = {
		oklab: ['<percentage>', '<number>', '<number>'],
		hsl: ['<number>', '<number>', '<percentage>'],
		srgb: ['<number>', '<number>', '<number>'],
	}

	function getSerializedValues(color) {
		const formatByCoords = color.space.getFormat('default')?.coords ?? []
		const preferredTypes = preferredTypesBySpace[color.space.id]
		return color.coords
			.map((coord, index) => {
				const type = formatByCoords[index].find(({ type }) => type === preferredTypes[index]) ?? formatByCoords[index][0]

				return type.serialize(coord, 5)
			})
	}

	const results = [
		new Color('oklab(88% 0.145 -0.392)'),
		new Color('hsl(270 50% 25%)'),
		new Color('rgb(100% 50% 22.33%)'),
	].map((color) => getSerializedValues(color))
	console.log(results)
	//> [ [ "88%", "0.145", "-0.392" ], [ "270", "50%", "25%" ], [ "255", "127.5", "56.942" ] ]
})()

However, this capability is not available for the alpha channel. One can serialize the alpha channel by hand using something like color.alpha.toPrecision(5).replace(/\.?0+$/, '') (this is just for the sake of illustration and not meant to be equivalent with what colorjs.io does internally), but the problem here is that this side-steps the internal precision logic.

So far, this covers serialization. What the library also handles is parsing. As far as I can tell, this functionality is not available to users for individual coords/alpha but only for complete colors.

Use case

I'm working on a color picker which, among other elements, has one input per coord/channel including alpha of the currently active format (e.g. H, S, L, A for HSL, R, G, B, A for RGB, and so forth). I'm in the process of replacing all the internal logic of the color picker with colorjs.io (saving me a ton of code for color conversions, etc.). This is almost complete, but the last puzzle is the serialization and deserialization between these input elements and my internal logic.

In short, I need to:

• construct a new Color() from independent HTMLInputElements for internal storage
• output that Color to those independent HTMLInputElements

Workarounds

• Serialization: custom implementation for alpha
• Parsing: trying to construct a CSS color out of the HTMLInputElements first and then letting new Color() parse it

I'm not a huge fan of these workarounds because it gives me little control over how I can react to partial/incomplete inputs (e.g. “12.%”) and because it means that the logic between serialization and parsing is separate and not necessarily matching. With one being in an external library, it could also get out of sync over time.

Notes & references

• I've previously started a discussion (Percentage number coords: why do the percentage value ranges of the sRGB Space coords differ from seemingly all others?) that relates to this
• Possibly related depending on if and how this is solved: It should be possible to output alpha as <percentage> #335

[LeaVerou]

Just a quick note to say the API shape for this is non-obvious to me right now, but the ask makes a lot of sense. Especially given the current complexity of parsing and serializing components, with keywords, NaN etc.

[kleinfreund]

Just a quick note to say the API shape for this is non-obvious to me right now

I think at least for the serialization side of the request, the color space method getFormat could yield a Format that also has a Type for alpha in addition the Types for coords (though unfortunately, alpha already exists on Formats). That would be consistent with the current interface for formats; however, it would be repetitive as alpha is special insofar as it always has the same definition for all color spaces (at least as far as I know).

I'm not super in love with the ergonomics of retrieving the "preferred type" per coordinate in the sample code I provided in the original issue, but it certainly works.

[kleinfreund]

I now published a version of my color picker using colorjs.io under the hood for as much as possible of the internal logic with the exception of parsing individual coords and alpha, and serializing alpha.

For reference, the relevant code that could be handled by colorjs.io should this functionality be exposed to users is the following:

• https://github.com/kleinfreund/vue-accessible-color-picker/blob/d9bda32733f9414fc5b03b68cf540ea0745a863f/src/constants.ts#L13-L171: defines which parsing algorithm to use for which coord of a specific color space
• https://github.com/kleinfreund/vue-accessible-color-picker/blob/d9bda32733f9414fc5b03b68cf540ea0745a863f/src/utilities/CssValues.ts: defines the parsing algorithms available in my color picker

That's ultimately not much code at all, but I don't like that I use colorjs.io for most of the serialization and my own code for parsing as that could lead to compound errors when repeatedly parsing and serializing coords.

A possible workaround (that I didn't want to entertain further, however) would be using colorjs.io's parsing facilities that are exposed via new Color() (or parse()). That would however still leave me with using my own logic for serializing alpha.

I do think exposing some general means to serialize and parse coords and alpha would be beneficial to other people than me (hopefully they come across this issue eventually^^).