Clean up token files ahead of JSON source of truth setup
Categories
(Toolkit :: Themes, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox126 | --- | fixed |
People
(Reporter: jules, Assigned: jules)
References
Details
Attachments
(1 file)
We're starting to solidify our tokens collection ahead of the work of setting up a JSON source of truth for design tokens (see 1850611).
Since we have been slowly adding tokens as their need arise for about a year now, I caught a few inconsistencies that we can benefit from cleaning ahead of landing the JSON source of truth:
Background
Color
Background color tokens today:
--color-background-information
--color-background-success
--color-background-warning
--color-background-critical
--color-canvas
--box-background-color
I propose a change that makes Background Color a default value with other variants:
--background-color
--background-color-information
--background-color-success
--background-color-critical
--background-color-warning
--background-color-box
Border
Color
Border color tokens today:
--border-color
--border-interactive-color
--border-interactive-color-hover
--border-interactive-color-active
--border-interactive-color-disabled
I propose a change that makes Border Color a default value with the interactive variant
--border-color
--border-color-interactive
--border-color-interactive-hover
--border-color-interactive-active
--border-color-interactive-disabled
The above proposed clean up still follow our taxonomy rules, but make up a more predictive naming system of variants just like icon for example.
Base vs Application tokens
In the past, we've stipulated that the Base token category is the foundational / hard-coded values that 'should not be used' directly since they don't carry semantic meaning (e.g. --color-blue-50
). However, by such definition of pointing directly to hard-coded values and not having a necessarily super meaningful name, there are a few other "Base" groups and scales such as border radius and font size that stores tokens that are referred to directly.
While it's good to have an understanding between the "Base" groups versus the more semantic group of tokens which we've labeled as "Application" tokens, I'm not sure the existing documentation and approach of this tier system make sense today, or whether the comment headings are helpful, so I recommend we find a clearer way to document such distinction.
Assignee | ||
Comment 1•1 year ago
|
||
Updated•1 year ago
|
Updated•11 months ago
|
Comment 3•11 months ago
|
||
Backed out for causing multiple failures
- Backout link
- Push with failures
- Failure Log dt
- Failure line: TEST-UNEXPECTED-FAIL | devtools/client/inspector/markup/test/browser_markup_screenshot_node_about_page.js | Uncaught exception in test bound - at chrome://mochitests/content/browser/devtools/client/inspector/markup/test/browser_markup_screenshot_node_about_page.js:17 - TypeError: can't access property "r", rgba is null
- Failure Log bc
- Failure line: TEST-UNEXPECTED-FAIL | browser/base/content/test/static/browser_parsable_css.js | custom property
--outline-color-error
is not referenced -
Comment 5•11 months ago
•
|
||
Backed out for causing dt failures (previous ones are not fixed)
- Backout link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-FAIL | devtools/client/inspector/markup/test/browser_markup_screenshot_node_about_page.js | Uncaught exception in test bound - at chrome://mochitests/content/browser/devtools/client/inspector/markup/test/browser_markup_screenshot_node_about_page.js:17 - TypeError: can't access property "r", rgba is null
Comment 7•11 months ago
|
||
bugherder |
Assignee | ||
Updated•11 months ago
|
Description
•