Re: [community-group] Native modes and theming support (#210)

Today for theming we just add a new theme file with the tokens defined in
the theme file overriding said tokens in the base file. This allows product
teams to create custom themes without messing with the core token file.

With the modes proposal, I do not see a mechanism for defining a mode
outside the main token definitions, or would it work the same way? Define
the same tokens a second time with just the additional mode value?



On Thu, 23 Mar, 2023, 9:02 am Nate Baldwin, ***@***.***>
wrote:

> I like this approach. I am curious if mode nesting in token definitions
> would be supported or explicitly disabled?
>
> For example, you have light and dark mode, but for each of those you also
> have increased and decreased contrast modes. Modes in this case could not
> be defined in isolation as there is some dependency (light + increased
> contrast, dark + increased contrast).
>
> Example contrast modes:
>
> {
>   "$name": "Figma UI Colors",
>   "$modes": {
>     "light": {},
>     "dark": {},
>     "increased-contrast": {}
>     "decreased-contrast": {}
>   },
>   // tokens ...
> }
>
> Examples with nesting:
>
>   "text-primary": {
>     "$type": "color",
>     "brand": {
>       "$modes": {
>         "light": {
>           "value":  "{colors.gray.800}",
>           "increase-contrast": "{colors.gray.900}",
> "decreased-contrast": "{colors.gray.700}"
>         },
>         "dark": {
>           "value":  "{colors.gray.200}",
>           "increase-contrast": "{colors.gray.100}",
> "decreased-contrast": "{colors.gray.300}"
>         }
>       }
>     }
>   }
>
> Alternatively, disallowing nesting for modes may provide a forcing
> function for aliasing (one level handles light/dark, another level handles
> contrast). Either I think are ok but should be considered.
>
> Similarly, it may be necessary to define which modes are relative to one
> another, or what token types they can support. Ie, "light", "dark", and
> "darkest" are enumerations for a property (eg, "colorScheme"), whereas
> "increase-contrast", "decreased-contrast" or even "forced-colors" would be
> enumerations for a different property (eg. "contrastModes"). That way we
> can enforce that you cannot nest/combine options of the same mode property
> (eg, "light": {"dark": "$token"}} is disallowed).
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/design-tokens/community-group/issues/210#issuecomment-1480552982>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AEKS36B4K5ZHJNAK7WWVIKDW5O76PANCNFSM6AAAAAAWEORCFY>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>


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


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

Received on Thursday, 23 March 2023 05:58:21 UTC