nesquarx
commented
1 year ago We define colors today as an OKLCH value if supported and failing that a hex value... How would we expect to implement this? Especially where the OKLCH does give more vibrant output than the hex on most modern displays.
On Thu, 22 Jun 2023 at 03:31, Matthew Simo @.***> wrote:
I think for the specification to be applicable by platforms other than the web the specification should include a way to define custom types.
In otherwords, I think it will be useful for the specification to allow a way to define schema in the top level of the document that can be used later in that same document. An example that could act as a model is how the openapi spec https://spec.openapis.org/oas/v3.1.0#schema does this to allow for composable advanced types for APIs. Nothing as complication should be necessary but something in that direction could provide the necessary extensibility.
24bit RGB or 24+8bit RGBA color in the sRGB color space is entirely reasonable for the web but becomes limiting especially as more and more displays are commonly supporting larger color gamuts https://developer.chrome.com/articles/high-definition-css-color-guide/.
For example, something like this.
{ "$schemas": [{ "$name": "hex-color" "$ref": "https://www.w3.org/TR/css-color-4/#hex-notation", "$version": "1.0.0" }], "Majestic magenta": { "$value": "#ff00ff", "$type": "$schemas.hex-color" }, "Translucent shadow": { "$value": "#00000080", "$type": "$schemas.hex-color" } }
Likewise, the supported values for the dimension type seems limiting too. For a web client, px and rem is a reasonable baseline even if they are only a fraction of the supported length units. Personally, I'd want at least the absolute https://developer.mozilla.org/en-US/docs/Web/CSS/length#absolute_length_units and font based relative https://developer.mozilla.org/en-US/docs/Web/CSS/length#relative_length_units_based_on_font CSS length units. Though there's also a strong argument for both viewport and container relative length units too. Many of these don't make sense for many platforms that tokens are consumed, but providing a way to define types helps avoid the issue.
If schemas support external references they would keep their footprint within the .tokens or .tokens.json file minimal. This would also allow platforms and tools to maintain their own declarations the community could benefit from and provide an easy path forward on providing Enums for the CSS Keywords I've seen discussed in other tickets.
Thanks for taking the time to read and consider.
— Reply to this email directly, view it on GitHub https://github.com/design-tokens/community-group/issues/221, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEKS36HPJUWWWUJZOZ7Z3OTXMNVLBANCNFSM6AAAAAAZPLDVY4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
matthewsimo
I think for the specification to be applicable by platforms other than the web the specification should include a way to define custom types.
In otherwords, I think it will be useful for the specification to allow a way to define schema in the top level of the document that can be used later in that same document. An example that could act as a model is how the openapi spec does this to allow for composable advanced types for APIs. Nothing as complication should be necessary but something in that direction could provide the necessary extensibility.
24bit RGB or 24+8bit RGBA color in the sRGB color space is entirely reasonable for the web but becomes limiting especially as more and more displays are commonly supporting larger color gamuts.
For example, something like this.
Likewise, the supported values for the dimension type seems limiting too. For a web client, px and rem is a reasonable baseline even if they are only a fraction of the supported length units. Personally, I'd want at least the absolute and font based relative CSS length units. Though there's also a strong argument for both viewport and container relative length units too. Many of these don't make sense for many platforms that tokens are consumed, but providing a way to define types helps avoid the issue.
If schemas support external references they would keep their footprint within the
.tokensor.tokens.jsonfile minimal. This would also allow platforms and tools to maintain their own declarations the community could benefit from and provide an easy path forward on providing Enums for the CSS Keywords I've seen discussed in other tickets.Thanks for taking the time to read and consider.