diff options
Diffstat (limited to 'toolkit/themes/shared/design-system/docs')
17 files changed, 676 insertions, 0 deletions
diff --git a/toolkit/themes/shared/design-system/docs/README.design-tokens.stories.md b/toolkit/themes/shared/design-system/docs/README.design-tokens.stories.md new file mode 100644 index 0000000000..52651c1d59 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/README.design-tokens.stories.md @@ -0,0 +1,386 @@ +# Design tokens + +## What are design tokens? + +Design tokens capture raw values that represent user interface design styling decisions, such as color or font size, with variables under a consistent naming structure that conveys purpose and intent. + +Design tokens are language-agnostic, and can be translated to any environment. On Firefox for desktop, variables are represented in CSS. + +For example, [moz-toggle](https://searchfox.org/mozilla-central/source/toolkit/content/widgets/moz-toggle) uses several design tokens. Here are a few: + +<table> + <tr> + <th>Component token</th> + <th>Alias of token</th> + <th>Value</th> + </tr> + <tr> + <td><code>--toggle-width</code></td> + <td><code>--size-item-large</code></td> + <td><code>32px</code></td> + </tr> + <tr> + <td><code>--toggle-background-color-pressed</code></td> + <td><code>--color-accent-primary</code></td> + <td><code>--color-blue-50</code>(<code>#0060df</code>)</td> + </tr> + <tr> + <td><code>--toggle-border-radius</code></td> + <td><code>--border-radius-circle</code></td> + <td><code>9999px</code></td> + </tr> +</table> + +Although the design tokens methodology is industry-wide, there is no one-size-fits-all approach. Therefore, our design tokens are defined and implemented for the purposes of serving Firefox UI. This document should capture everything you need to know about [our design system's](https://acorn.firefox.com/) design tokens. + +The goal is for all of us who work on Firefox to share a common and maintainable system for how we refer to and consume UI styles, and for Firefox UI to be styled consistently. + +## Taxonomy + +_The following documentation borrows from Nathan Curtis' essay on [Naming Design Tokens](https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676)._ + +Design tokens' variable names follow a taxonomy with distinct classification levels and sublevels, forming a prescriptive vocabulary of descriptive terms which are classified by category. + + + +### Ecosystem +The ecosystem level helps describe the context that a token is scoped to. + +#### Domain +A token is only prefixed with a domain when there is a need to specify its context. + +For example, if a token is specific to a certain feature, you can use the domain level to specify the name of the feature that it belongs to. Don't forget to keep domain-specific tokens within the feature's CSS so that they can only be reused within its domain. + +Example from [browser/components/shopping/content/shopping-container.css](https://searchfox.org/mozilla-central/rev/02841791400cf7cf5760c0cfaf31f5d772624253/browser/components/shopping/content/shopping-container.css#7): + + + +### Objects +The object level helps define the object (or objects) that the token applies to. + +#### Pattern +A design pattern that is composed of, or represents, multiple related components. + + + +#### Component +The component name. + + + +#### Nested element +Any element that may be nested within a component (e.g. an icon). + + + +### Categories +The category level helps define the visual style that apply to the token. + +#### Type +The type of style category a design token belongs to. + + + +#### Concept +A concept further describes user interface styles. They are either industry-wide patterns, or they are terms determined by our team based on specific user interface style needs. For example, "accent" is a common design industry term used for deliniating a brand's or product's accent color(s) that we happen to use for our color tokens. + + + +To further illustrate this taxonomy level, here are detailed explanations and definitions of existing concepts: + +##### Accent +We use the "accent" color concept for referring to our brand and the operating system (platform) accent colors. The brand and platform accent colors are used as the primary color for accentuating and characterizing several Firefox UI elements' (e.g. buttons, focus outlines, links, icons, and more). + +##### Interactive +We use the "interactive" concept to describe design tokens that pertain to interactive elements. For example, `--border-color-interactive` is used on [moz-toggle](https://searchfox.org/mozilla-central/rev/956e25260926097a4d54d5aeb0e06347841616bf/toolkit/content/widgets/moz-toggle/moz-toggle.css#40) since interactive elements such as toggles, radios, and checkboxes share the same border color pattern that is different from our default border color. + +```css +/* moz-toggle.css */ +--toggle-border-color: var(--border-color-interactive); +``` + +##### Item +We use the "item" concept as a modifier on top of the "size" type tokens group to refer to different interface items, or elements, that often rely on the same standard width and height dimensions. The word item should imply that this is a small sizing scale dedicated for dimensions that get applied to smaller UI pieces such as icons, logos, and avatars, as opposed to large compositions or areas such as the width set for onboarding illustrations, or the width of a sidebar or main column within a page's template. + +```css +/* tokens-shared.css */ +--size-item-small: 16px; +--size-item-large: 32px; +``` + +#### Property +A property (e.g. size, width, color, fill) further describes a design tokens' style, although this is not to be confused with the categorical type of token mentioned above, albeit they often use similar terms. Note that sometimes properties are double-worded, and that's totally fine (e.g. min-width, background-color) + + + +### Modifiers +The modifier level helps further classify a design token's characteristic with further specification. + +#### Variant +A variant specifies a token from a group of tokens related by a common meaning but that have varying purpose. + + + +#### State +A state defines possible intereactive states of a design token. +(e.g. hover, active, focus, disabled) + + + +#### Scale +A scale defines a collection of tokens that relate to one another's but vary by their type, such as a collection of size units, or any other relationship that requires differentiating tokens by a determined scale. + + + +Today we have scales based off a sequence of numbers or t-shirt sizing. + +We use a sequence numbers for collections that have attributes that change as the number goes up, such as colors getting darker. + +Number-based scale grows by 10: + * 10 + * 20 + * 30 + * 40 + * 50 + * 60 + * and so on... + +For collections that do have sizing relationships, we use t-shirt sizing names: + + * xsmall + * small + * medium + * large + * xlarge + * xxlarge + * and so on... + +These are some of our font sizes as an example: + +```css +/* tokens-brand.css */ +--font-size-root: 15px; +--font-size-small: 0.867rem; /* 13px */ +--font-size-large: 1.133rem; /* 17px */ +--font-size-xlarge: 1.467rem; /* 22px */ +``` + +You will see that the font size scale is missing what would be a logical "medium" size in between "small" and "large", and that it has a `--font-size-root` within it too; that's because we use more specific words within scales that contain tokens that serve a specific purpose within that scale. + +The `--font-size-root` token was created for specific use under the document's `:root` in order to set the default font size for our relative typography scale. We label our default font size token as `root` in order to be specific **and** intentional. + + + +It's okay to include intentional terms within scales that better represent the meaning of a value and when to use it. For example, our border radius collection, which uses t-shirt sizing, also mixes the 'circle' option within its scale in order to describe a border radius that will create a circular effect: + + + + +## Naming guidelines +The goal of design tokens naming is modularity and legibility. + + + +Meanings and the relationship between meanings can be complex, therefore taxonomy levels are chained to provide clarity. (see example above) + +The example above also helps illustrate that not all levels are required when naming a token. A name just needs enough levels to imply the token's use and define its meaning. Different combinations of different levels helps us arrive at meaningful names. + +Names shouldn't be redundant and should be kept simple. They should only include enough levels to describe and communicate the token's intent and purpose. + +## How it works +The desktop tokens system serves our browser's two different ecosystems, the chrome and in-content (about:) pages, since they don't always share the same styling decisions, and consequently, values. + +The chrome of the browser is styled to look and feel like it belongs to the user's operating system, and to also support theming. Therefore typography and color rules are different from the rest of our application features that load within in-content pages. + +### Token files +Token files are stored in the [design-system](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system) folder within `toolkit/themes/shared`. + +Tokens are split between three stylesheets: brand, platform, and shared. + +```sh +└── toolkit + └── themes + └── shared + └── design-system + ├── tokens-brand.css + ├── tokens-platform.css + └── tokens-shared.css +``` + +A token's context is the key to understanding the relationship between these stylesheets. If a token isn't set at the shared level, that means that it has different values between brand and platform contexts. + +Shared tokens ([tokens-shared.css](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system/tokens-shared.css)) are imported into brand tokens ([tokens-brand.css](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system/tokens-brand.css)) and platform tokens ([tokens-platform.css](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system/tokens-platform.css)). + +[common-shared.css](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/in-content/common-shared.css) imports `tokens-brand.css` so that in-content/about: pages can make use of our brand values, while [global-shared.css](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/global-shared.css), which styles the chrome, imports `tokens-platform.css` so that the chrome can access operating system and themeable values. + + + +#### `tokens-brand.css` +This file is for token values specific to the brand, such as colors and +typographical styles. This stylesheet should be loaded in domains that rely on +brand values. + +For example, we re-map the accent color token in `tokens-brand.css` to the +value we want to use in brand contexts (in-content/about: pages): +```css +/* tokens-brand.css */ +--color-accent-primary: light-dark(var(--color-blue-50), var(--color-cyan-50)); +``` + +#### `tokens-platform.css` +This file is for token values used the browser chrome that come from the user’s +operating system, such as colors and fonts. + +For example, we re-map the accent color token in `tokens-platform.css` to the +value we want to use in platform contexts (chrome): +```css +/* tokens-platform.css */ +--color-accent-primary: var(--button-primary-bgcolor, AccentColor); +``` + +#### `tokens-shared.css` +This file is for tokens that are shared between brand and platform contexts. + +For example, both the chrome and in-content pages make use of the same border-radius patterns: +```css +/* tokens-shared.css */ +--border-radius-small: 4px; +``` + +### Tiers +#### Base +Base design tokens represent the most basic, or foundational, groups of design tokens that point to the actual hard-coded values of the design system. They can be referenced to create more meaningful tokens. + +```css +/* tokens-shared.css */ +--color-blue-50: #0060df; +--color-blue-60: #0250bb; +--color-blue-70: #054096; +``` + +#### Application +Application design tokens represent the more semantic groups of design tokens that give meaning to base values based on their purpose or how/where they are applied. + +```css +/* tokens-brand.css */ +--color-accent-primary: light-dark(var(--color-blue-50), var(--color-cyan-50)); +``` + +#### Component +Component design tokens represent design tokens scoped to a specific component or element. While the "Application" tier can handle most if not all styling use cases, tier 3 helps encapsulate style decisions at the component level. + +Although some component-specific tokens for basic HTML elements (e.g. button) live in `tokens-shared.css` today, component-specific tokens should live at the component-level file (e.g. [moz-toggle.css](https://searchfox.org/mozilla-central/rev/02841791400cf7cf5760c0cfaf31f5d772624253/toolkit/content/widgets/moz-toggle/moz-toggle.css#34-50)) so that they can't be used outside of that specific component's domain. + +```css +/* moz-toggle.css */ +--toggle-background-color-pressed: var(--color-accent-primary); +``` + +### File structure +Design token files are structured for organization and consumption purposes. + +Token groups should be listed by alphabetical order: +Border, Color, Font Weight... + +A comment heading should be added above each token group with its name: +```css +/** Color **/ +--color-white: #ffffff; +--color-blue-05: #deeafc; +--color-blue-30: #73a7f3; +... +``` + +Design tokens should be listed by alphabetical order: +```css +/** Focus outline **/ +--focus-outline: var(--focus-outline-width) solid var(--focus-outline-color); +--focus-outline-color: var(--color-accent-primary); +--focus-outline-inset: calc(-1 * var(--focus-outline-width)); +--focus-outline-offset: 2px; +--focus-outline-width: 2px; +``` + +Scale groups should be listed from the beginning to the end of the scale (i.e. smallest to largest value). +Any semantic tokens within a scale, such as the `--font-size-root` example below, can be listed above it: + +```css +/** Font size **/ +--font-size-root: 15px; +--font-size-small: 0.867rem; /* 13px */ +--font-size-large: 1.133rem; /* 17px */ +--font-size-xlarge: 1.467rem; /* 22px */ +--font-size-xxlarge: 2.2rem; /* 33px */ +``` + +## Theming +For certain components, their high-contrast mode design will need styles that other modes do not (e.g. HCM relies on borders that do not exist in non-HCM). In those instances, we just add tokens under the high contrast mode media query rules. On the other hand, if something such as a color, does not apply to HCM contexts, then we add those design tokens under a "@media not (prefers-contrast)" query. + +### Light and dark +We rely on the [light-dark()](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/light-dark) CSS function to set light and dark mode colors at the token assignment level. + + +```css +/* tokens-shared.css */ +--icon-color: light-dark(var(--color-gray-70), var(--color-gray-05)); +``` + +### High contrast mode +We rely on two queries for assigning HCM counterpart variables, @media (prefers-contrast) and @media (forced-colors). They are found at the bottom of [tokens-shared.css](https://searchfox.org/mozilla-central/rev/6eb2ebcafb1b4a8576eb513e6cd2c61e3f3ae6dc/toolkit/themes/shared/design-system/tokens-shared.css#109). + +/* This part of the documentation will link to Bug 1863436 once it lands */ + +## Help and support +If you have any questions, concerns, or feedback, and if this document has not answered something specific, please reach out to Desktop Theme Reviewers or Reusable Components Reviewers. + +The Reusable Components team can be found on Matrix at [#reusable-components](https://matrix.to/#/#reusable-components:mozilla.org), and theme reviewers can be found at [#fx-theme-reviewers](https://matrix.to/#/#fx-desktop-theme:mozilla.org). You're also welcome to request info from any of us on Bugzilla. + +Tag us on your Phabricator patch via **#desktop-theme-reviewers** and **#reusable-components-reviewers**. + +Internal only: we are also on Mozilla's internal Slack at [#acorn-design-tokens](https://app.slack.com/client/T027LFU12/C046F5U05M1). This channel is dedicated to our design token working group. We also host weekly open-discussion sessions on Zoom; please reach out if you'd like an invite to the meeting. + +## Contributing +For proposing contributions to [design token files](#token-files), please [file a bug under the Theme component](https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit&component=Themes). + +If any feature work may require a change or addition to token files, filing a follow-up bug is recommended. + +Token file changes or additions should be handled with their own bug and patch. Please add a detailed commit message following this changelog format: + +```markdown +Added +* ... + +Changed +* ... + +Deprecated +* ... + +Removed +* ... + +Fixed +* ... +``` + +Teams that generate component and feature specific tokens are welcome to [reach out to theme and reusable components reviewers for support](#help-and-support). diff --git a/toolkit/themes/shared/design-system/docs/README.json-design-tokens.stories.md b/toolkit/themes/shared/design-system/docs/README.json-design-tokens.stories.md new file mode 100644 index 0000000000..1081481f9f --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/README.json-design-tokens.stories.md @@ -0,0 +1,290 @@ +# JSON design tokens +## Background +The benefit of storing design tokens with a platform-agnostic format such as JSON is that it can be converted or translated into other languages or tools (e.g CSS, Swift, Kotlin, Figma). + +## Quick start +`design-tokens.json` holds our source of truth for design tokens in `mozilla-central` under the [design-system](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system) folder in `toolkit/themes/shared`. The CSS design token files in that folder come from the JSON file. If you need to modify a design token file, you should be editing the JSON. + +In order for us to be able to define design tokens in one place (the JSON file) and allow all platforms to consume design tokens in their specific format, we use a build system called [Style Dictionary](https://amzn.github.io/style-dictionary/#/). + +Here's how to build design tokens for desktop: + +```sh +$ ./mach buildtokens +``` + +If successful, you should see Style Dictionary building all of our tokens files within the `design-system` folder. Otherwise, Style Dictionary can also generate helpful errors to help you debug. + +At the end, we're capable of transforming JSON notation into CSS: + +```json +{ + "color": { + "blue": { + "05": { + "value": "#deeafc" + }, + "30": { + "value": "#73a7f3" + }, + "50": { + "value": "#0060df" + }, + "60": { + "value": "#0250bb" + }, + "70": { + "value": "#054096" + }, + "80": { + "value": "#003070" + } + }, + }, +} +``` + +```css +--color-blue-05: #deeafc; +--color-blue-30: #73a7f3; +--color-blue-50: #0060df; +--color-blue-60: #0250bb; +--color-blue-70: #054096; +--color-blue-80: #003070; +``` + +Neat! + +## Testing + +We have basic tests in place to ensure that our built CSS files stay up to date +and that new tokens are properly categorized. These tests will fail if the JSON +is modified but the command to build the tokens CSS files doesn't run, or if the +tokens CSS files are modified directly without changing the JSON. + +Our tests are Node-based to allow us to install and work with the +`style-dictionary` library, and follow a format that has been used previously +for Devtools and New Tab tests. + +You can run the tests locally using the following command: + +```sh +$ ./mach npm test --prefix=toolkit/themes/shared/design-system +``` + +## JSON format deep dive + +Style Dictionary works by ingesting JSON files with tokens data and performing various platform-specific transformations to output token files formatted for different languages. The library has certain quirks and limitations that we had to take into consideration when coming up with a JSON format for representing our tokens. The following is a bit of a "how to" guide for reading and adding to [`design-tokens.json`](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system/design-tokens.json) for anyone who needs to consume our tokens or add new tokens. + +### Naming + +When going from token name to JSON, each place we would insert a hyphen, underscore, or case change in a variable name translates to a layer of nesting in our JSON. That means a token with the CSS variable name `--border-radius-circle` would be represented as: + +```json +"border": { + "radius": { + "circle": { + "value": "9999px" + } + } +} +``` + +The `value` key is required as this is the indicator [Style Dictionary looks for](https://amzn.github.io/style-dictionary/#/architecture?id=_4a-transform-the-tokens) to know what sections of the JSON to parse into distinct tokens. It gets omitted from the final variable name. + +For simple cases `value` will be either a string or a number, but when we have to take media queries or themes into account `value` will be an object. Examples of these cases will be explained in more detail below. + +### `@base` + +When reading through our JSON you will see many instances where we have used an `@base` key, always appearing right before a `value` key indicating that everything up to that point should be parsed as a token. For example our `--font-weight` CSS token is represented like this in our JSON: + +```json +"font": { + "weight": { + "@base": { + "value": "normal" + } + } +} +``` +This is a workaround for a [known](https://github.com/amzn/style-dictionary/issues/119) [limitation](https://github.com/amzn/style-dictionary/issues/366) of Style Dictionary where it doesn't support nested token names that appear after a `value` key. If we want to have both `--font-weight` and `--font-weight-bold` CSS tokens they need to be represented as distinct objects with their own `value`s: + +```json +"font": { + "weight": { + "@base": { + "value": "normal" + }, + "bold": { + "value": 600 + } + } +} +``` +`@base` is a special indicator we chose to enable Style Dictionary to parse our tokens correctly while still generating our desired variable names. Much like `value`, it ultimately [gets removed](https://searchfox.org/mozilla-central/rev/159929cd10b8fba135c72a497d815ab2dd5a521c/toolkit/themes/shared/design-system/tokens-config.js#94-96) from the final token name. + +You will also see many places where `@base` is referenced in a value definition. This is a bit of a gotcha - even though `@base` isn't part of the token name, we still need to include it when using Style Dictionary's syntax for [variable references/aliases](https://amzn.github.io/style-dictionary/#/tokens?id=referencing-aliasing). That means the following CSS: + +```css +--input-text-min-height: var(--button-min-height); +``` + +Will look like this in our JSON: + +```json +"input": { + "text": { + "min": { + "height": { + "value": "{button.min.height.@base}" + } + } + } +} +``` + +### High Contrast Mode (HCM) media queries + +We need to be able to change our token values to support both the `prefers-contrast` and `forced-colors` [media queries](https://firefox-source-docs.mozilla.org/accessible/HCMMediaQueries.html). We employ `prefersContrast` and `forcedColors` keys nested in a token's `value` key to indicate that we need to generate a media query entry for that token. For example this JSON: + +```json +"border": { + "color": { + "interactive": { + "@base": { + "value": { + "prefersContrast": "{text.color.@base}", + "forcedColors": "ButtonText", + } + } + }, + } +} +``` +results in the following CSS: + +```css +/* tokens-shared.css */ + +@layer tokens-prefers-contrast { + @media (prefers-contrast) { + :root, + :host(.anonymous-content-host) { + /** Border **/ + --border-color-interactive: var(--text-color); + } + } +} + +@layer tokens-forced-colors { + @media (forced-colors) { + :root, + :host(.anonymous-content-host) { + /** Border **/ + --border-color-interactive: ButtonText; + } + } +} +``` + +### Theming + +Our JSON supports two dimensions of theming designed around the needs of the Firefox desktop client; light and dark themes, and brand and platform themes. + +#### Light and dark themes + +We employ `light` and `dark` keys in our `value` objects to indicate when a given token should have different values in our light and dark themes: + +```json +"background": { + "color": { + "box": { + "value": { + "light": "{color.white}", + "dark": "{color.gray.80}", + } + }, + } +} +``` + +The above JSON communicates that `--background-color-box` should have the value of `var(--color-white)` in our light theme and `var(--color-gray-80)` in our dark theme. + +If a token has the same value for both the light and dark themes it will either have a string or number as its `value` or it will use a `default` key: + +```json +"button": { + "background": { + "color": { + "disabled": { + "value": { + "default": "{button.background.color.@base}", + } + } + } + } +} +``` + +The above JSON indicates that `--button-background-color-disabled` will have the value of `var(--button-background-color)` regardless of theme. + +#### Brand and platform themes + +The Firefox desktop client consists of [two distinct surfaces](https://acorn.firefox.com/latest/resources/browser-anatomy/desktop-ZaxCgqkt#section-anatomy-fd); "the chrome," or the UI of the browser application that surrounds web pages, and the web content itself which is often referred to as "in-content." Firefox UI development spans both surfaces since our `about:` pages are "in-content" pages. In our design system we distinguish between these surfaces by using the terminology of `platform` vs `brand`. Chrome specific token values live in [`tokens-platform.css`](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system/tokens-platform.css) and in-content specific token values live in [`tokens-brand.css`](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/design-system/tokens-brand.css). + +We use `platform` and `brand` keys in our JSON to indicate when a token has a surface-specific value. For example this token definition: + +```json +"text": { + "color": { + "@base": { + "value": { + "brand": { + "light": "{color.gray.100}", + "dark": "{color.gray.05}" + }, + "platform": { + "default": "currentColor" + } + } + }, + } +} +``` +communicates that `--text-color` should have the value `currentColor` in `tokens-platform.css` for chrome surfaces, and the value `light-dark(var(--color-gray-100), var(--color-gray-05))` in `tokens-brand.css` for in-content pages. The resulting CSS spans multiple files: + +```css +/* tokens-platform.css */ +@layer tokens-foundation { + :root, + :host(.anonymous-content-host) { + /** Text **/ + --text-color: currentColor; + } +} +``` + +```css +/* tokens-brand.css */ +@layer tokens-foundation { + :root, + :host(.anonymous-content-host) { + /** Text **/ + --text-color: light-dark(var(--color-gray-100), var(--color-gray-05)); + } +} +``` + +### Adding new tokens + +In order to add a new token you will need to make changes to `design-tokens.json` - any files generated based on our JSON token definitions should never be modified directly. You should be able to work backwards from the variable name in whatever language you're working with to figure out the correct JSON structure. + +Once you've made your changes, you can generate the new tokens CSS files by running `./mach buildtokens`. + +If you encounter errors or get unexpected results when running the build command it may be because: + +* You forgot to nest everything in a `value` key and consequently Style Dictionary is not parsing your tokens correctly, or; +* You omitted `@base` when referencing another token, or; +* You are referencing another token that you haven't defined in the JSON yet - Style Dictionary should give descriptive error messages in this case. + +If you need any help feel free to reach out in #firefox-reusable-components on Slack or #reusable-components on Matrix. diff --git a/toolkit/themes/shared/design-system/docs/img/categories-concept-example.png b/toolkit/themes/shared/design-system/docs/img/categories-concept-example.png Binary files differnew file mode 100644 index 0000000000..6fc7681898 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/categories-concept-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/categories-property-example.png b/toolkit/themes/shared/design-system/docs/img/categories-property-example.png Binary files differnew file mode 100644 index 0000000000..0304beb049 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/categories-property-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/categories-type-example.png b/toolkit/themes/shared/design-system/docs/img/categories-type-example.png Binary files differnew file mode 100644 index 0000000000..6a8cba0377 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/categories-type-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/component-name-example.png b/toolkit/themes/shared/design-system/docs/img/component-name-example.png Binary files differnew file mode 100644 index 0000000000..14aaf57516 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/component-name-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/ecosystem-domain.png b/toolkit/themes/shared/design-system/docs/img/ecosystem-domain.png Binary files differnew file mode 100644 index 0000000000..a2024fd6bc --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/ecosystem-domain.png diff --git a/toolkit/themes/shared/design-system/docs/img/modifiers-border-radius-example.png b/toolkit/themes/shared/design-system/docs/img/modifiers-border-radius-example.png Binary files differnew file mode 100644 index 0000000000..fe94e2855e --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/modifiers-border-radius-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/modifiers-font-size-example.png b/toolkit/themes/shared/design-system/docs/img/modifiers-font-size-example.png Binary files differnew file mode 100644 index 0000000000..8df20aa7b6 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/modifiers-font-size-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/modifiers-naming-guidelines.png b/toolkit/themes/shared/design-system/docs/img/modifiers-naming-guidelines.png Binary files differnew file mode 100644 index 0000000000..3197e53cc5 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/modifiers-naming-guidelines.png diff --git a/toolkit/themes/shared/design-system/docs/img/modifiers-scale-example.png b/toolkit/themes/shared/design-system/docs/img/modifiers-scale-example.png Binary files differnew file mode 100644 index 0000000000..6d39a1a740 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/modifiers-scale-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/modifiers-state-example.png b/toolkit/themes/shared/design-system/docs/img/modifiers-state-example.png Binary files differnew file mode 100644 index 0000000000..2d24c1af28 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/modifiers-state-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/modifiers-variant-example.png b/toolkit/themes/shared/design-system/docs/img/modifiers-variant-example.png Binary files differnew file mode 100644 index 0000000000..bd854d923e --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/modifiers-variant-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/nested-element-example.png b/toolkit/themes/shared/design-system/docs/img/nested-element-example.png Binary files differnew file mode 100644 index 0000000000..8f6db5c329 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/nested-element-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/objects-pattern-example.png b/toolkit/themes/shared/design-system/docs/img/objects-pattern-example.png Binary files differnew file mode 100644 index 0000000000..f26500d131 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/objects-pattern-example.png diff --git a/toolkit/themes/shared/design-system/docs/img/taxonomy-overview.png b/toolkit/themes/shared/design-system/docs/img/taxonomy-overview.png Binary files differnew file mode 100644 index 0000000000..d5df5622e4 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/taxonomy-overview.png diff --git a/toolkit/themes/shared/design-system/docs/img/token-files-hierarchy.png b/toolkit/themes/shared/design-system/docs/img/token-files-hierarchy.png Binary files differnew file mode 100644 index 0000000000..423fc4ccf5 --- /dev/null +++ b/toolkit/themes/shared/design-system/docs/img/token-files-hierarchy.png |
