We're starting to solidify our [tokens collection](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system) ahead of the work of setting up a JSON source of truth for design tokens (see [1850611](https://bugzilla.mozilla.org/show_bug.cgi?id=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` ## Component-specific tokens [We have tokens tied to input elements](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#81-95) stored in `tokens-shared.css` today. They're pretty specific to inputs and we should likely find a better home for them as they don't seem to need to exist at the shared level. The button tokens may take a bit of work since several elements rely on it, but for the other input element tokens, I believe they're only being used in-content today so we can potentially just keep them in `common-shared.css` for now.
Bug 1881821 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
We're starting to solidify our [tokens collection](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system) ahead of the work of setting up a JSON source of truth for design tokens (see [1850611](https://bugzilla.mozilla.org/show_bug.cgi?id=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](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#74-79) for example. ## Component-specific tokens [We have tokens tied to input elements](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#81-95) stored in `tokens-shared.css` today. They're pretty specific to inputs and we should likely find a better home for them as they don't seem to need to exist at the shared level. The button tokens may take a bit of work since several elements rely on it, but for the other input element tokens, I believe they're only being used in-content today so we can potentially just keep them in `common-shared.css` for now.
We're starting to solidify our [tokens collection](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system) ahead of the work of setting up a JSON source of truth for design tokens (see [1850611](https://bugzilla.mozilla.org/show_bug.cgi?id=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](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#74-79) for example. ## Base vs Application tokens In the past, we've treated the [Base](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#10) token category as the foundational values that 'should not be used' since they don't carry semantic meaning (e.g. `--color-blue-50`). However, we're no longer sure that makes the most sense since people are welcome to create new meanings. We also noticed a few base scales such as border radius, font size, and font weight should be listed under Base since they're the base scale for those categories. ## Component-specific tokens [We have tokens tied to input elements](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#81-95) stored in `tokens-shared.css` today. They're pretty specific to inputs and we should likely find a better home for them as they don't seem to need to exist at the shared level. The button tokens may take a bit of work since several elements rely on it, but for the other input element tokens, I believe they're only being used in-content today so we can potentially just keep them in `common-shared.css` for now.
We're starting to solidify our [tokens collection](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system) ahead of the work of setting up a JSON source of truth for design tokens (see [1850611](https://bugzilla.mozilla.org/show_bug.cgi?id=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](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#74-79) for example. ## Base vs Application tokens In the past, we've treated the [Base](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#10) token category as the foundational values that 'should not be used' directly since they don't carry semantic meaning (e.g. `--color-blue-50`). However we are no longer sure that makes sense since there are a few other base scales such as border radius, font size, and font weight that are used directly and should technically be listed under the "Base" comment heading since they're the base scale for those categories. Let's not include a comment saying "Base" shouldn't be used and also group all of those base scales together. ## Component-specific tokens [We have tokens tied to input elements](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#81-95) stored in `tokens-shared.css` today. They're pretty specific to inputs and we should likely find a better home for them as they don't seem to need to exist at the shared level. The button tokens may take a bit of work since several elements rely on it, but for the other input element tokens, I believe they're only being used in-content today so we can potentially just keep them in `common-shared.css` for now.
We're starting to solidify our [tokens collection](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system) ahead of the work of setting up a JSON source of truth for design tokens (see [1850611](https://bugzilla.mozilla.org/show_bug.cgi?id=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](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#74-79) for example. ## Base vs Application tokens In the past, we've stipulated that the [Base](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#10) token category is the foundational / raw 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 raw values and not having a necessarily super meaningful name, there are a few other "Base" groups and scales such as [border radius](https://searchfox.org/mozilla-central/rev/aff9f084975de6123b96aaa7c2edf31304c7c8c4/toolkit/themes/shared/design-system/tokens-shared.css#47-49) and [font size](https://searchfox.org/mozilla-central/rev/aff9f084975de6123b96aaa7c2edf31304c7c8c4/toolkit/themes/shared/design-system/tokens-brand.css#35-40) 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. ## Component-specific tokens [We have tokens tied to input elements](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#81-95) stored in `tokens-shared.css` today. They're pretty specific to inputs and we should likely find a better home for them as they don't seem to need to exist at the shared level. The button tokens may take a bit of work since several elements rely on it, but for the other input element tokens, I believe they're only being used in-content today so we can potentially just keep them in `common-shared.css` for now.
We're starting to solidify our [tokens collection](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system) ahead of the work of setting up a JSON source of truth for design tokens (see [1850611](https://bugzilla.mozilla.org/show_bug.cgi?id=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](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#74-79) for example. ## Base vs Application tokens In the past, we've stipulated that the [Base](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#10) 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](https://searchfox.org/mozilla-central/rev/aff9f084975de6123b96aaa7c2edf31304c7c8c4/toolkit/themes/shared/design-system/tokens-shared.css#47-49) and [font size](https://searchfox.org/mozilla-central/rev/aff9f084975de6123b96aaa7c2edf31304c7c8c4/toolkit/themes/shared/design-system/tokens-brand.css#35-40) 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. ## Component-specific tokens [We have tokens tied to input elements](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#81-95) stored in `tokens-shared.css` today. They're pretty specific to inputs and we should likely find a better home for them as they don't seem to need to exist at the shared level. The button tokens may take a bit of work since several elements rely on it, but for the other input element tokens, I believe they're only being used in-content today so we can potentially just keep them in `common-shared.css` for now.
We're starting to solidify our [tokens collection](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system) ahead of the work of setting up a JSON source of truth for design tokens (see [1850611](https://bugzilla.mozilla.org/show_bug.cgi?id=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](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#74-79) for example. ## Base vs Application tokens In the past, we've stipulated that the [Base](https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/themes/shared/design-system/tokens-shared.css#10) 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](https://searchfox.org/mozilla-central/rev/aff9f084975de6123b96aaa7c2edf31304c7c8c4/toolkit/themes/shared/design-system/tokens-shared.css#47-49) and [font size](https://searchfox.org/mozilla-central/rev/aff9f084975de6123b96aaa7c2edf31304c7c8c4/toolkit/themes/shared/design-system/tokens-brand.css#35-40) 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.