Re: [community-group] Loosen up the color type (#79)

> What is the practical benefit of allowing colorSpace to be anything?

It gives authors and parsers the maximum latitude, and makes it much easier for this format to be forward-compatible. If we define error handling well (eg, what happens when a parser sees a color space it doesn't support), I see the agreement between authors' needs and parsers' feature set as being a sort of "invisible hand" that can guide the ecosystem.

> In what way is xyz-d65 futuristic or fancy?

I realize that "fancy futuristic color spaces" might have sounded pejorative. I'm sorry, I should have phrased that differently.

Fancy because:
  1. xyz is unintuitive, eg white is [1,1,1] in rgb but [95.047,  100.000,  108.883] in xyz-d65
  2. converting colors into xyz space requires linear algebra – from srgb needs the additional step of conversion to linear rgb before going to xyz

Futuristic because:
  1. most design tools don't support xyz colors today
  2. css color 4 does support xyz, but it isn't implemented yet in most browsers

> I am strongly against hex strings. I don't see why I need to complicate my tool's implementation by adding support for this format in the parser logic.

I think the fact that hex strings are one of the most commonly-used and commonly-supported color formats makes them an extremely useful medium of exchange. It would be good to be clear about _how much_ complication it introduces, compared to the value it represents to token authors.

> This is unusual, the most often used technical term is "channels"

A bit of bikeshedding, but a few examples:

Wikipedia uses both interchangeably. From [RGB Color Model](https://en.wikipedia.org/wiki/RGB_color_model): "The color is expressed as an RGB triplet (r,g,b), each **component** of which can vary from zero to a defined maximum value." And "This indirect scheme restricts the number of available colors in an image CLUT—typically 256-cubed (8 bits in three color **channels** with values of 0–255)"

The [CSS color module level 4](https://www.w3.org/TR/css-color-4/) spec also uses them interchangeably. "Colors in CSS are represented as a list of color **components**, also sometimes called '**channels**'."

[SwiftUI's docs](https://developer.apple.com/documentation/swiftui/color) use 'component' exclusively: "Specify **component** values, like red, green, and blue; hue, saturation, and brightness; or white level."

[Kotlin's docs](https://developer.android.com/reference/kotlin/android/graphics/Color) use 'component' exclusively: "A color int always defines a color in the sRGB color space using 4 **components** packed in a single 32 bit integer value".

I don't feel strongly either way, "components" is just a personal preference.

---
> If the expectation is that colors will be mostly manually typed then hex can be useful.
> However this format is intended to be written and read by software.

> Do we need the extra complication of a dual format?
> It adds extra burden on tools to write the parser logic for colors.
> It isn't much, but little things add up.

If token files are meant _only_ as a data interchange format, it follows that a color should be encoded in a single way (to reduce encoder/decoder complexity), in high fidelity (many bits per channel/component), without any loss (widest possible gamut). An array of floats representing a `xyz-d65` color plus a single float for alpha would be a great candidate for this.

If token files are meant _only_ as human-written-and-read documentation tools, it follows that an author should have the freedom to write colors in whichever format is most convenient to them, as long as that format is unambiguous to whoever is reading the file later.

In reality, we're trying to land somewhere in the middle. I don't think we'll ever have a perfect measuring rod for the solution, but it's going to involve some compromise between parser complexity and author ergonomics.

---

> Only the data format and the list of color spaces are a factor for the design token file format. Everything else is irrelevant.

100% agreed.

-- 
GitHub Notification of comment by ilikescience
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/79#issuecomment-1402222582 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 24 January 2023 16:22:16 UTC