Extensible Types

[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.

{
  "$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 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 .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.

[nesquarx]

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/>. <https://camo.githubusercontent.com/1a3b054520094f3f0cc5e4b399484f6f80435ce5e1532c5fd2a6db0691012d5e/68747470733a2f2f77642e696d6769782e6e65742f696d6167652f76533036485131595473624d4b53465449506c32696f6755515037332f427356646d366673484f3842306d42676b4851462e706e673f6175746f3d666f726d617426773d383435> 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": "#80", "$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 <#221>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKS36HPJUWWWUJZOZ7Z3OTXMNVLBANCNFSM6AAAAAAZPLDVY4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[matthewsimo]

Ideally, I'd think the spec should define a comprehensive list of useful types, including oklab & oklch.

However, with the extensible types idea I'm proposing it could look something like this:

{
  "$schemas": {
    "oklch-color": {
      "$properties": {
        "l": {
          "$name": "lightness",
          "$types": ["percentage", "number"],
        },
        "c": {
          "$name": "chroma",
          "$types": ["percentage", "number"],
        },
        "h": {
          "$name": "hue",
          "$types": ["number", "angle"],
        }
      },
    },
  },
  "Majestic magenta": {
    "$value": {
      l: "70.17%",
      c: 0.322, 
      h: 328.36,
    },
    "$type": "$schemas.oklch-color"
  },
}

Note: This is inspired by the openapi spec and I'm not necessarily promoting this format or structure - it's just for illustrative purposes. Also, it assumes some generic types that the spec provides like "percentage", "number", "angle", which I'm taking from https://www.w3.org/TR/css-values-4/#numeric-types