Create theme-unaware high-level tokens

[rajsite]

🙋 Feature Request

😯 Problem to Solve

We currently have:

• theme-unaware base tokens such as $ni-nimble-base-black-85 that are static values defined as raw values
• theme-aware high-level tokens such as $ni-nimble-application-background-color that are dynamic values that change at runtime based on JavaScript, the nimble-theme-provider custom element, and programmatically updating CSS Custom Property values

We should consider having:

• theme-unaware high-level tokens such as $ni-nimble-application-background-color-light-theme, $ni-nimble-application-background-color-dark-theme, $ni-nimble-application-background-color-color-theme that are static values defined as raw values
• we should then build the theme-aware high-level tokens from those theme-unaware high-level tokens

Use-cases:

• Mobiscroll does not support theming using dynamic CSS custom properties and needs statically defined SCSS values (discussion)
• Gainsights does not support JavaScript execution which is needed for our theme-aware high-level tokens to update dynamically. We could instead generate static CSS styles that use prefers-color-scheme to have top-level page system theme awareness (but no concept of theme-providers to override themes on specific regions of a page dynamically).

💁 Proposed Solution

Partially described above but we need to determine:

• The naming scheme for theme unaware high-level tokens
• How to represent the theme-unaware high-level tokens in style dictionary
• Generation of static CSS that uses the prefers-color-scheme media query (current use-case being gainsights so should see what is actually supported first)

📋 Tasks

[jattasNI]

https://github.com/ni/nimble/pull/2305/files/2699ec4760c024a1d150cea9b3df50c01992c46c revealed some of the challenges in doing this:

1. we need hierarchy in base tokens to avoid duplicating hex values and to provide clarity about which tokens are atomic color values and which are mapping to component parts / variants
2. we need a naming scheme that incorporates the many subtle parts / variants / themes / token types
3. we want a way to simplify the theme-aware token creation so that it doesn't require a single file importing hundreds of base tokens and manually mapping them