Re: [community-group] Legacy color (#137)

At a minimum, whatever capabilities we add to the Color Type in future iterations, token authors who hand-edit their files must be able to specify a color using only a HEX value represented as a string.

My view is that the current spec as authored (where Color is specified via HEX) satisfies a couple of [key principles](https://www.designtokens.org) of this group.

Namely:
> Inclusive: Allow anyone to become familiar with design tokens. **Empower people, no matter what their skills and tool choices are**, as they develop new mental models, acquire skills, and implement tools to scale design in their projects.

and:

> Focused, yet extensible: **Stay focused on the smallest surface area necessary to cover the most commonly referenced use-cases.** Be a platform that opens the door to a wide range of possibilities. This small footprint helps maintain simplicity with zero dependencies. Extensibility allows the community to incubate new ideas that will define the future of design tokens.

My read of those principles as applied to the Color Type and some of the proposals in this thread:

First - **Empower people, no matter what their skills and tool choices are** 
I'm very concerned about a spec change that would _require_ a token author to specify a color space and a use a notation that may be unfamiliar to many. HEX, for all its shortcomings, is widely understood and standardized not just across tools, but also in the minds of many many designers and developers across multiple fields (not just web). It may be an insufficient format for what modern screens are capable of, but it's well established and that carries weight in the form of familiarity. That familiarity will aid in the spec's adoption by those who are familiar with HEX and have no need for colors in a wider gamut.

If we _require_ specification of color spaces and array notation to specify color, we'll be placing an additional burden on many token spec adopters to not only learn the design token format, but possibly a whole new means of specifying colors they already have documented elsewhere in HEX. My concern is that this requirement would be so off-putting that it will limit the adoption of the specification as a whole.

To argue the counterpoint, you could say the current spec is **not** inclusive because it excludes those who wish to use colors from a wider-gamut. The lack of wider-gamut color space support is off-putting to those that wish to define their colors in something more powerful than HEX provides. For that group, I lean on the second principle:
**Stay focused on the smallest surface area necessary to cover the most commonly referenced use-cases.**

I believe we are doing that by norming on the most commonly used representation of color _in our current ecosystem_.

**All that said,** I want to be future-looking in a _future_ version of the spec. I believe something like @c1rrus proposed in https://github.com/design-tokens/community-group/issues/137#issuecomment-1166543573 would be the most inclusive syntax we could adopt - supporting both the _today_ mindset of HEX and the _future_ mindset of wider-gamut colors.

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


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

Received on Monday, 25 July 2022 14:58:41 UTC