- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Tue, 24 Jan 2023 16:45:32 +0000
- To: public-design-tokens-log@w3.org
> 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. That is not technically accurate. ### 1 The specification allows `colorSpace` to be any string value. - tool X might have an implementation for a value : `alpha`. - tool Y might have an implementation for a value : `beta`. Neither are real color spaces. Both tools are following the specification. This would be allowed. **There would be no interop of design tokens between tools.** ### 2 The specification allows `colorSpace` to be any known color space but it doesn't specify a list of color spaces. It only requires that a color space must have a specification published by orgs/groups X, Y, Z,.... - tool X might have an implementation for a value : `alpha`. - tool Y might have an implementation for a value : `ALPHA`. - tool Z might have an implementation for a value : `beta`. All are real color spaces. All tools are following the specification. **There would be no interop of design tokens between tools.** - `alpha` is a new color space that was released "today". - tool X might have an implementation for a value : `alpha`. - tool Y doesn't have support (yet) for `alpha`. All tools are following the latest specification and can claim to implement it fully. **There would be no interop of design tokens between tools.** ------- Allowing this to be any value doesn't benefit forwards compat in any way. Even worse it makes it harder by not triggering an error. Tools that encounter a color space they do not support would have to invent some magic to still produce an output token but would not be able to correctly process the actual value. ------- > I don't feel strongly either way, "components" is just a personal preference. Interesting! Yes I think this is something that can differ greatly based on personal experience. I also do not have a strong preference. As long as it is something that makes sense for a lot of people. -------- > 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. I don't mind a more complex parser. But currently the specification doesn't support this. There is only `$type` and that is not sufficient to have both a simple hex string and a future proof color notation as referenced above. **Either the specification needs to be greatly expanded or we will have to make compromises on what can be expressed in the format.** If we have to pick either hex or a future proof color notation then I think it is obvious that we should not pick hex. But that is my personal opinion :) -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/79#issuecomment-1402256731 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:45:34 UTC