- From: Henry Wilkinson via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Nov 2022 05:38:48 +0000
- To: public-design-tokens-log@w3.org
[Because feedback was requested](https://www.youtube.com/watch?v=ssOdzxZdg58) and digital color is a particular area of interest (and often frustration!) for me... Here are some thoughts! +1 to alpha as a separate distinct channel. Alpha [(according to its creators)](https://graphics.pixar.com/library/Compositing/) represents a percentage of occlusion and has _no interaction_ with the colour encoding model, colourspace, or its values until it's time to composite the image. Some formats (CSS' `rgba()` specifically) treat alpha as part of the colour data for convenience, but design token values can always compile down to those in the end if people so choose while offering the added benefit of specificity. Adding other data channels (depth, normals, motion vectors, [deep](https://en.wikipedia.org/wiki/Deep_image_compositing), etc) can be done much the same way! While alpha and depth can be represented by single values, the others mentioned here have 3 values each. At this point we're encoding full pixels, not _just_ colours... But we were doing that before with the inclusion of "alpha" so are arbitrary channels _really_ out of scope? 🙃 ### On hex codes... +1 for using and actually enforcing non-hex values. Hex codes offer an incredibly oversimplified method of moving colour information around and can really only be relied upon to deliver 8-bit sRGB data (_sometimes_ 8-bit P3 data if you use the macOS colour picker! Therefore, the same hex value can be interpreted _completely differently_ by software! Awful!) Regarding [this comment](https://github.com/design-tokens/community-group/issues/137#issuecomment-1194163443) in #137, I argue that hex is widely _misunderstood_ by almost everyone who uses it! Hex codes transfer no colour space information yet many designers consistently expect them to operate as if "this is a colour value" when instead all they are _actually_ transferring is an RGB value which means _nothing_ without a defined colourspace, hence the sRGB assumption. Hex codes themselves obscure the 8-bit integer RGB value reality such that people really have no idea _what_ they're actually transferring, only that when they copy this code the same colour appears in both places. I find this format is not at all empowering for non-technical users as it provides another layer of obfuscation to what people are actually doing when manipulating digital colour values. RE @romainmenke's [comment](https://github.com/design-tokens/community-group/issues/137#issuecomment-1281895256) in the same thread, I would love for design tokens themselves to replace hex codes as a standardized method of colour data transfer, perhaps with the added data we could finally _accurately_ move colour information between programs! Hex as an encoding format inherently achieves none of this and should be abandoned wherever possible. ### Why not go with the status quo? Building on that, please do not restrict this spec based on what is _possible_ in today's design software that you are familiar with. You are writing a spec for people to _follow_, push the industry forward! Tailoring a spec only to what is possible in current software adds barriers to moving both software and the spec forward in the future (see SVG & digital colour). If the initial reality is that programs only implement _part_ of a properly defined colour spec, they can do the rest later with newly added incentive to actually handle colours _correctly_. Here are two specific things I'd like to see: - Per-channel / component 8, 16, **and** 32-bit int / float values supported. The design programs of today pail in comparison to the computer graphics industry where 32-bit values are _required_ for accurate photo-real compositing. Programs like [Nuke](https://www.foundry.com/products/nuke-family/nuke) and [Blender ](https://www.blender.org/) _exclusively_ support entering RGB values as floats. Given the design industry's adoption of 3D software, I would propose that these value types be supported properly to enable the accurate transport of colour information between programs that require _and output_ this colour data through industry standard formats like [OpenEXR](https://github.com/AcademySoftwareFoundation/openexr) (which notably supports every value type I've mentioned here). They haven't signed onto this spec yet and they won't if they _can't_. More colour aware DCCs aside, [> 8 bit colour is already being used in the world for UI design work today!](https://netflixtechblog.com/enhancing-the-netflix-ui-experience-with-hdr-1e7506ad3e8) The browser and subsequently Electron aren't the only content delivery methods. ;) - Colourspace included as a seperate field. RGB is a colour encoding model, sRGB, P3, and rec2020 are all colour spaces with a defined white point, primaries plotted against the [standard observer model](https://en.wikipedia.org/wiki/CIE_1931_color_space), and a transfer function that relates the non-linear encoding of RGB values within the colourspace to the linear nature of light. We can probably skip defining colour encoding models separately as they can be reverse engineered from the `colorspace` value if need be, but this value is a **MUST**. Without it you are making assumptions and assumptions (as detailed above) will eventually result in an inaccurate transfer of colour information at the user level. Even with sRGB this colourspace value _should be defined every time_. Looks like this is already happening and there aren't many arguments about not doing it so uh, thank you! :) Thank you for reading my spiel <3 Here's one bonus question! ### What's in scope regarding colour? The "design systems world" seems to revolve pretty much entirely around digital work, but as I'm sure we're all aware, component & defined-style-centric design work extends past the screen and the need for sharing colour data extends past RGB. Is the CMYK colour encoding model in scope? Data needs to travel along with _that_ too, and it's all printer specific information which is hard to standardize in specs like this! Perhaps this would be something to leave for a later version of the spec... but something to think about! -- GitHub Notification of comment by Shrinks99 Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/79#issuecomment-1327040218 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 25 November 2022 05:38:50 UTC