docs: create how to work with design tokens #26

dcoa · 2024-09-05T09:02:04Z

This PR adds a how-to about design tokens support for the brand package.

There are still details to evaluate such as whether should we install Paragon as a dev dependency and the possible creation of a Paragon CLI command specific to this package.

Any early feedback should be great @brian-smith-tcril and @PKulkoRaccoonGang.

openedx-webhooks · 2024-09-05T09:02:09Z

Thanks for the pull request, @dcoa!

This repository is currently maintained by @openedx/committers-brand-openedx.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
- This process (including the steps you'll need to take) is documented here.
If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

Dependencies

This PR must be merged before / after / at the same time as ...
Blockers

This PR is waiting for OEP-1234 to be accepted.
Timeline information

This PR must be merged by XX date because ...
Partner information

This is for a course on edx.org.
Supporting documentation
Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

The size and impact of the changes that it introduces
The need for product review
Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

brian-smith-tcril

Thank you so much for putting this together! This is looking wonderful! I left a few comments with questions, more about possible ways to streamline the process than the documentation itself.

docs/how-to/design-tokens-support.rst

brian-smith-tcril · 2024-09-20T19:51:22Z

docs/how-to/design-tokens-support.rst

+How to structure the brand design tokens
+========================================
+
+The file structure in the brand package should be the same as the version of Paragon used as a reference to allow the merge/override during the build time.
+
+.. code-block::
+  
+    .
+    └── tokens/
+        └── src/
+            ├── core/
+            │   └── <name_of_the_folder>/
+            │       └── <name_of_the_file>.json
+            └── themes/
+                ├── light/
+                │   └── <name_of_the_folder>/
+                │       └── <name_of_the_file>.json
+                ├── dark/
+                │   └── <name_of_the_folder>/
+                │       └── <name_of_the_file>.json
+                └── my-theme/
+                    └── <name_of_the_folder>/
+                        └── <name_of_the_file>.json


Open question here: the current structure of this repo has paragon as a directory at the top level. Is the plan to have tokens as a directory at the top level, or is the plan to have paragon/tokens?

Good idea. Perhaps consumers can have their own system design and their own set of token designs. It would be nice to have such a named structure for tokens provided by Paragon

Understanding that the brand package contains more than only paragon related code and the guide is related to how to use it with the paragon design system makes sense to have the tokens into the paragon folder.

brian-smith-tcril · 2024-09-20T19:58:01Z

docs/how-to/design-tokens-support.rst

+How to structure the brand design tokens
+========================================
+
+The file structure in the brand package should be the same as the version of Paragon used as a reference to allow the merge/override during the build time.


It might be nice to link to and/or provide a URL format for the paragon tokens directory from here

https://github.com/openedx/paragon/tree/v23.0.0-alpha.3/tokens currently works to show the directory for the v23.0.0-alpha.3 tag, so maybe having something like

To see the tokens directory structure for the version of Paragon you are targeting you can navigate to https://github.com/openedx/paragon/tree/TARGET_PARAGON_VERSION/tokens. For example, if you were targeting Paragon v23.0.0 you would navigate to https://github.com/openedx/paragon/tree/v23.0.0/tokens.

could work

brian-smith-tcril · 2024-09-20T20:00:00Z

docs/how-to/design-tokens-support.rst

+In terms of tokens, Paragon follows the specifications of the `Design Tokens Community Group <https://tr.designtokens.org/format/#abstract>`_. 
+
+The structure that follows to define most of the tokens is ``category > item > subitem > property > state``, for example:
+
+.. code-block:: json
+  
+    {
+      "spacing": {    // Category
+        "$type": "dimension",                         
+        "annotation": {    // Item 
+          "padding": {     // Property
+              "$value": ".5rem",
+              "$source": "$annotation-padding"
+          },
+          "arrow-side": {   // Subitem
+            "margin": {     // Property
+              "$value": "{spacing.annotation.padding},
+              "$source": "$annotation-arrow-side-margin"
+            }
+          }
+        }
+      },
+      "typography": {
+        "annotation": {
+          "font-size": { 
+          "source": "$annotation-font-size", 
+          "$value": "{typography.font.size.sm}", 
+          "$type": "dimension" 
+          },
+        }
+      },
+    }
+
+Each token has specific attributes:
+
+- **Value**: It is the value that will be assigned to the variable, which could be a value or a reference, such as l arrow-side in the above example.
+- **Type**: Indicates the property to be processed (color, dimension, etc..). This value could be defined for the token itself or a group of tokens (e.g. spacing)
+- **Source**: This value is additional and indicates the equivalent in saas notation.
+- **Modify**: Optional value that helps to apply a specific token modification.
+
+Use the ``source`` attribute to map the tokens in Paragon and create the theme files. Also, it will help you to replace the values in scss files if you have custom variables (see below).
+
+You can check `Paragon tokens <https://github.com/openedx/paragon/tree/alpha/tokens>` to know the folder and token structure, and how to work with modifiers.


This part feels like it could go under a separate heading. That way we'd have a section for where to put files and how to name them, and a section for what to put in those files.

brian-smith-tcril · 2024-09-20T20:05:01Z

docs/how-to/design-tokens-support.rst

+#. Install Paragon
+
+.. code-block:: bash
+    
+    npm install paragon


I wonder if it makes sense to add Paragon as a dev dependency for this repo instead of instructing people to install it. Then we could just have people run npm ci and people wouldn't end up with changes to their package.json and package-lock.json files.

This should be updated in paragon as well https://github.com/openedx/paragon/tree/alpha?tab=readme-ov-file#theming-with-design-tokens

brian-smith-tcril · 2024-09-20T20:07:01Z

docs/how-to/design-tokens-support.rst

+      }
+    }
+    
+Replace the destination with the desired path and run the command, it is recommended to use ``./dist/``. 


Is there a specific reason to have this as a template instead of just hardcoding ./dist/?

highlight and in any case be use in the package.json file as the destination for the script template

brian-smith-tcril · 2024-09-20T20:11:50Z

docs/how-to/design-tokens-support.rst

+
+It is recommended to create the `theme-urls.json` if you are working with runtime theming and want to use ``ParagonWebpackPlugin`` to preload the token URLs during the application build time.
+
+The file must be in the ``dist`` folder and should have:


I'm not the biggest fan of having people directly create/edit files in the dist directory. It'd be great to be able to .gitignore dist and have this file copied in as part of the build process.

I think could live in the paragon/tokens folder, referencing all the desired variants. May be in this way, we will need to be clear about the relative path (understanding that the design tokens destination path is not necessary the dist folder, it is the ideal but is not limited to it)

with the improvements in the Paragon CLI the file could be created automatically, I add a new command and try to clarify that in the how-to

mphilbrick211 · 2024-10-24T20:44:22Z

Hi @dcoa! Just checking in on this!

dcoa · 2024-10-25T03:48:33Z

Hi, @mphilbrick211 this is a work in progress I will allocate some time in the following weeks to finish it. Sorry for that.

PKulkoRaccoonGang · 2024-10-27T14:40:13Z

docs/how-to/design-tokens-support.rst

+===================================
+
+
+From version 23 `Paragon <https://www.notion.so/Write-the-brand-docs-7a60ece8489e40e1a6ca6ac4b79aac82?pvs=21>`_ supports CSS variables and 


[question]: Will there be a link here to the future npm Paragon 23 page?

Paragon Documentation, yes

Thanks, resolved

PKulkoRaccoonGang · 2024-10-27T14:45:13Z

docs/how-to/design-tokens-support.rst

+    .
+    └── tokens/
+        └── src/
+            ├── core/


[question]: Is it worth specifying here more precisely which directories may be needed? For example, now in the alpha version of Paragon we have semantic tokens that we divide into core, alias and global tokens? More information on semantic design tokens

I think due to the the how-to is explaining how to work with the paragon design tokens version I think a mention and a link to that explanation about semantic tokens is a valuable addition. I don't want to duplicate the information if it is already in Paragon. As well, I think the user should decide the folders that they want to include I mean if I want to change a token in the component folder worth it add the global and aliases as well?

Thanks for the explanation 💯

PKulkoRaccoonGang · 2024-10-27T14:47:50Z

docs/how-to/design-tokens-support.rst

+How to structure the brand design tokens
+========================================
+
+The file structure in the brand package should be the same as the version of Paragon used as a reference to allow the merge/override during the build time.
+
+.. code-block::
+  
+    .
+    └── tokens/
+        └── src/
+            ├── core/
+            │   └── <name_of_the_folder>/
+            │       └── <name_of_the_file>.json
+            └── themes/
+                ├── light/
+                │   └── <name_of_the_folder>/
+                │       └── <name_of_the_file>.json
+                ├── dark/
+                │   └── <name_of_the_folder>/
+                │       └── <name_of_the_file>.json
+                └── my-theme/
+                    └── <name_of_the_folder>/
+                        └── <name_of_the_file>.json


Good idea. Perhaps consumers can have their own system design and their own set of token designs. It would be nice to have such a named structure for tokens provided by Paragon

PKulkoRaccoonGang · 2024-10-27T14:50:11Z

docs/how-to/design-tokens-support.rst

+
+In terms of tokens, Paragon follows the specifications of the `Design Tokens Community Group <https://tr.designtokens.org/format/#abstract>`_. 
+
+The structure that follows to define most of the tokens is ``category > item > subitem > property > state``, for example:


It might be a good idea to add an image from the documentation site here
How do you like my proposal?

mphilbrick211 · 2025-02-12T21:46:37Z

Hi @dcoa! Is this still in progress?

dcoa · 2025-02-12T23:03:48Z

Hi @mphilbrick211, yes it is

ihor-romaniuk · 2025-05-07T07:03:12Z

paragon/core.scss

@@ -0,0 +1,4 @@
+// this file creates the core.css import here all the common styles for your theme. 


I noticed that we’ve introduced a new common file to consolidate all token build files and other related styles — that looks great!

However, I’m unsure how this will be used across all MFEs. Since we can’t reference files from this package via absolute paths, they need to be explicitly imported in the index.scss file of each MFE.

While reviewing your PRs in the MFEs, I also saw that all imports from this package were removed. This might limit our ability to override styles directly and easily, as we used to.

Additionally, I found that some files in the @edx/brand package — like paragon/_fonts.scss, paragon/_overrides.scss, paragon/_variables.scss, and the new paragon/core.scss — don’t appear to be used anywhere.

One more thing: we still have @edx/brand listed in package.json, but the package itself doesn’t seem to be in use.

Let me know if I missed anything or misunderstood the intention — happy to discuss!

Thanks for the questions!

I think this how-to document in frontend-platform should provide some good context as to how MFEs load themes/custom styles with Paragon 23/design tokens.

The PR that added design tokens support to frontend-build might also be helpful to look at openedx/frontend-build#546.

Hopefully those ease some concerns about being able to override styles!

I think we can resolve this too

brian-smith-tcril

Thank you so much for putting this together!

I can't think of anything else to add here. @PKulkoRaccoonGang @adamstankiewicz @MaxFrank13 - any thoughts on this one?

adamstankiewicz · 2025-05-21T16:14:24Z

docs/how-to/design-tokens-support.rst

+#. Once it is installed in the application use the Paragon CLI with the ``replace-variables`` command to use your custom tokens.
+
+
+The ``theme-urls.json`` file


[consideration] Does the brand package README need to mention anything about theme-urls.json? I believe it should be more of an implementation detail that theme authors shouldn't necessarily need to know about / do anything with manually.

When running npm run build in edx/elm-theme or edx/brand-edx.org, for example, a theme-urls.json file is automatically created within dist, e.g. as seen on NPM's package source code preview:

Given it's created automatically within the build-scss command (source) which brand packages use, I think this section from the README could be removed? 🤔

adamstankiewicz · 2025-05-21T16:16:30Z

package.json

+    "@openedx/paragon": "^23.0.0"
  }
 }
+


nit: looks like line 27 might be non-empty (e.g., spaces/indent), so GitHub is showing that file needs a blank new line at the end of file.

adamstankiewicz · 2025-05-21T16:19:13Z

docs/how-to/design-tokens-support.rst

+takes `style dictionary token structure <https://styledictionary.com/info/tokens/#category--type--item>`_ as inspiration:
+
+
+.. image:: ./style_diccionary_tokens.webp


nit: typo in file name

Suggested change

.. image:: ./style_diccionary_tokens.webp

.. image:: ./style_dictionary_tokens.webp

adamstankiewicz · 2025-05-21T16:20:17Z

docs/how-to/design-tokens-support.rst

+          "source": "$annotation-font-size", 
+          "$value": "{typography.font.size.sm}", 
+          "$type": "dimension" 


nit: these 3 lines are under-indented

adamstankiewicz · 2025-05-21T16:22:26Z

docs/how-to/design-tokens-support.rst

+
+- **Value**: It is the value that will be assigned to the variable, which could be a value or a reference, such as l arrow-side in the above example.
+- **Type**: Indicates the property to be processed (color, dimension, etc..). This value could be defined for the token itself or a group of tokens (e.g. spacing)
+- **Source**: This value is additional and indicates the equivalent in saas notation.


[consider] I might suggest not mentioning source in the brand package, as it's mostly relevant for the core Paragon tokens, not the brand token overrides. For example, if a brand package overrides an existing @openedx/paragon token that itself uses source, the token in the brand package will still have / inherit the original source.

The main reason why I left source in the explanation was the comment bellow. However, I'm not against the recommendation.

https://github.com/openedx/brand-openedx/pull/26/files#diff-26010d3309a977df1bd197514007774722f7f0afde99a35b868424ed6f034ef1R88

I think fully removing references to source in this document will encourage better practices than leaving documentation about it in. Ideally theme authors that create new tokens will consume them using CSS variables in their MFEs, as opposed to creating new SCSS variables mapping them using source.

adamstankiewicz · 2025-05-21T16:26:25Z

package.json

  "version": "1.0.0-semantically-released",
  "description": "The default branding and SASS theme package containing for Open edX applications. This package is designed to be copied and customized.",
+  "scripts": {
+    "build-tokens": "paragon build-tokens --source ./paragon/tokens/ --build-dir ./paragon/build -t dark -t light",


There is no dark theme variant yet; should we avoid including -t dark until there is an official dark theme variant?

I use this as a template to demonstrate how to use it with multiple themes. Despite paragon does not have more variants besides light, that does not limit brand package to create those. I tried to explain here https://github.com/openedx/brand-openedx/pull/26/files#diff-26010d3309a977df1bd197514007774722f7f0afde99a35b868424ed6f034ef1R109
Let me know what do you think, or should I explain better

I think having multiple variants mentioned in the how-to document makes perfect sense, but I don't think having it in this package.json makes sense just yet.

adamstankiewicz · 2025-05-21T16:32:33Z

package.json

  "description": "The default branding and SASS theme package containing for Open edX applications. This package is designed to be copied and customized.",
+  "scripts": {
+    "build-tokens": "paragon build-tokens --source ./paragon/tokens/ --build-dir ./paragon/build -t dark -t light",
+    "build-dist-files": "rm -rf dist && mkdir dist && paragon build-scss --corePath ./paragon/core.scss --themesPath ./paragon/build/themes --source",


Might recommend doing something to edx/elm-theme (source), where there's a single build NPM script that runs a Makefile build target (source). That build target subsequently runs npm run build-tokens and npm run build-scss.

Example:

{ "scripts": { "build-tokens": "...", "build-scss": "...", "build": "make build", "build:watch": "nodemon --ignore dist -x \"make build\"", } }

build: rm -rf dist && mkdir dist npm run build-tokens npm run build-scss

Note: the build:watch assumes nodemon is installed. This script was helpful during local development / QA of edx/elm-theme to avoid needing to manually re-run the build scripts on every change to the tokens to update the dist.

I applied the change

adamstankiewicz · 2025-05-21T16:32:57Z

package.json

+  "scripts": {
+    "build-tokens": "paragon build-tokens --source ./paragon/tokens/ --build-dir ./paragon/build -t dark -t light",
+    "build-dist-files": "rm -rf dist && mkdir dist && paragon build-scss --corePath ./paragon/core.scss --themesPath ./paragon/build/themes --source",
+    "pgn": "paragon help"


[consider] Might rename pgn to paragon:help to be more explicit that this is a help command related to paragon.

adamstankiewicz · 2025-05-21T16:35:16Z

paragon/core.scss

@@ -0,0 +1,4 @@
+// this file creates the core.css import here all the common styles for your theme. 
+
+// @import "./build/core/variables";


should we recommend/demonstrate using @use vs. @import in the SCSS files, given @import is technically deprecated within sass?

Some related reading:

https://sass-lang.com/documentation/at-rules/use/

https://medium.com/@philip.mutua/difference-between-use-and-import-in-scss-1cb6f501e649

adamstankiewicz · 2025-05-21T16:40:33Z

package.json

  "version": "1.0.0-semantically-released",
  "description": "The default branding and SASS theme package containing for Open edX applications. This package is designed to be copied and customized.",
+  "scripts": {
+    "build-tokens": "paragon build-tokens --source ./paragon/tokens/ --build-dir ./paragon/build -t dark -t light",


If we're assuming brand packages will be defining their tokens under ./paragon/tokens, should we have that directory already created when this repo is used as a template for a custom brand package? For example, while this package wouldn't define any token overrides itself, we could have an empty tokens directory with a .gitkeep so it stays in the git history.

I didn't create any folder understanding that previously to open this PR there was another one doing that #16 but if managing all in a unique place is easier for reviewing I can create the folder

I think creating the directories as empty with .gitkeep would be a great addition to this PR!

docs/how-to/design-tokens-support.rst

PKulkoRaccoonGang · 2025-05-22T09:08:23Z

I can't think of anything else to add here. @PKulkoRaccoonGang @adamstankiewicz @MaxFrank13 - any thoughts on this one?

I don't have the access to resolve discussions in this repository, so all my previous comments can be safely resolved. Thanks!

[inform]: I left one new question here

brian-smith-tcril

Thanks again for your patience throughout this review process!

We looked this over during Paragon WG this week - most things are looking great! I left a few responses to a couple threads.

brian-smith-tcril · 2025-05-28T15:18:34Z

docs/how-to/design-tokens-support.rst

+The ``theme-urls.json`` file
+=============================
+
+It is recommended to create the `theme-urls.json` if you are working with runtime theming for use the installed package as a fallback, or if want to use 


It is recommended to create the theme-urls.json

Since this is automatically generated when using the Paragon CLI, I don't think recommending manually creating this file is something we should be doing in this how-to.

I do think documenting the intended purpose and function of each part of theme-urls.json is valuable, but that can live in a standalone document.

brian-smith-tcril · 2025-05-28T15:24:00Z

package.json

  "version": "1.0.0-semantically-released",
  "description": "The default branding and SASS theme package containing for Open edX applications. This package is designed to be copied and customized.",
+  "scripts": {
+    "build-tokens": "paragon build-tokens --source ./paragon/tokens/ --build-dir ./paragon/build -t dark -t light",


I think having multiple variants mentioned in the how-to document makes perfect sense, but I don't think having it in this package.json makes sense just yet.

brian-smith-tcril · 2025-05-28T15:28:29Z

docs/how-to/design-tokens-support.rst

+
+- **Value**: It is the value that will be assigned to the variable, which could be a value or a reference, such as l arrow-side in the above example.
+- **Type**: Indicates the property to be processed (color, dimension, etc..). This value could be defined for the token itself or a group of tokens (e.g. spacing)
+- **Source**: This value is additional and indicates the equivalent in saas notation.


I think fully removing references to source in this document will encourage better practices than leaving documentation about it in. Ideally theme authors that create new tokens will consume them using CSS variables in their MFEs, as opposed to creating new SCSS variables mapping them using source.

brian-smith-tcril · 2025-05-28T15:31:43Z

package.json

  "version": "1.0.0-semantically-released",
  "description": "The default branding and SASS theme package containing for Open edX applications. This package is designed to be copied and customized.",
+  "scripts": {
+    "build-tokens": "paragon build-tokens --source ./paragon/tokens/ --build-dir ./paragon/build -t dark -t light",


I think creating the directories as empty with .gitkeep would be a great addition to this PR!

dcoa · 2025-05-28T22:32:53Z

@brian-smith-tcril , @adamstankiewicz thank you for your time reviewing this, I applied your latest comments 😀

brian-smith-tcril · 2025-06-05T17:28:42Z

@adamstankiewicz did you want to take one last look at this one?

adamstankiewicz

Looks great! Appreciate your updates, @dcoa!

openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Sep 5, 2024

dcoa requested review from PKulkoRaccoonGang and brian-smith-tcril September 5, 2024 09:02

brian-smith-tcril reviewed Sep 20, 2024

View reviewed changes

vunguyen-dmt pushed a commit to vunguyen-dmt/brand-openedx that referenced this pull request Oct 15, 2024

fix: add styling for header theme toggle switch button (openedx#26)

b3a1ae6

PKulkoRaccoonGang suggested changes Oct 27, 2024

View reviewed changes

dcoa force-pushed the dcoa/design-tokens-support branch 7 times, most recently from 47b7209 to 719dec8 Compare November 18, 2024 11:51

zemogle pushed a commit to zemogle/brand-openedx that referenced this pull request Jan 8, 2025

fix: add styling for header theme toggle switch button (openedx#26)

2d7cab6

dcoa added 2 commits March 13, 2025 20:05

docs: create how to work with design tokens

a45cd89

refactor: add paragon as dev dependency and update how to

c2b12c7

dcoa force-pushed the dcoa/design-tokens-support branch from ff7fdbe to c2b12c7 Compare March 13, 2025 09:06

feat: improve documentation and creates themes-url file by CLI

841ca6b

dcoa force-pushed the dcoa/design-tokens-support branch from 34e229c to 841ca6b Compare March 24, 2025 01:47

dcoa marked this pull request as ready for review March 24, 2025 01:51

brian-smith-tcril mentioned this pull request Mar 31, 2025

[DEPR] Branding without design tokens #23

Open

ihor-romaniuk reviewed May 7, 2025

View reviewed changes

ihor-romaniuk mentioned this pull request May 9, 2025

feat: design tokens support openedx/frontend-app-publisher#1003

Merged

mphilbrick211 moved this from Waiting on Author to In Eng Review in Contributions May 12, 2025

brian-smith-tcril mentioned this pull request May 15, 2025

Milestone 1: Plugin Scaffolding and Configuration Setup openedx/openedx-tutor-plugins#33

Merged

brian-smith-tcril approved these changes May 20, 2025

View reviewed changes

adamstankiewicz reviewed May 21, 2025

View reviewed changes

PKulkoRaccoonGang reviewed May 22, 2025

View reviewed changes

docs/how-to/design-tokens-support.rst Outdated Show resolved Hide resolved

openedx-webhooks added the core contributor PR author is a Core Contributor (who may or may not have write access to this repo). label May 22, 2025

dcoa added 2 commits May 27, 2025 09:31

style: fiixing typos and formatting

63c5e31

refactor: simplify build command

4e329d7

dcoa force-pushed the dcoa/design-tokens-support branch from 3962069 to 4e329d7 Compare May 27, 2025 01:10

brian-smith-tcril reviewed May 28, 2025

View reviewed changes

docs: apply feedback

f81ebef

PKulkoRaccoonGang approved these changes May 29, 2025

View reviewed changes

adamstankiewicz approved these changes Jun 6, 2025

View reviewed changes

brian-smith-tcril merged commit 0f4bc05 into openedx:master Jun 6, 2025
2 checks passed

github-project-automation bot moved this from In Eng Review to Done in Contributions Jun 6, 2025

github-project-automation bot moved this to Done in Design Tokens Project Board Jun 6, 2025


		It is recommended to create the `theme-urls.json` if you are working with runtime theming and want to use ``ParagonWebpackPlugin`` to preload the token URLs during the application build time.

		The file must be in the ``dist`` folder and should have:

		===================================


		From version 23 `Paragon <https://www.notion.so/Write-the-brand-docs-7a60ece8489e40e1a6ca6ac4b79aac82?pvs=21>`_ supports CSS variables and


		In terms of tokens, Paragon follows the specifications of the `Design Tokens Community Group <https://tr.designtokens.org/format/#abstract>`_.

		The structure that follows to define most of the tokens is ``category > item > subitem > property > state``, for example:

		@@ -0,0 +1,4 @@
		// this file creates the core.css import here all the common styles for your theme.

		#. Once it is installed in the application use the Paragon CLI with the ``replace-variables`` command to use your custom tokens.


		The ``theme-urls.json`` file

		takes `style dictionary token structure <https://styledictionary.com/info/tokens/#category--type--item>`_ as inspiration:


		.. image:: ./style_diccionary_tokens.webp

	.. image:: ./style_diccionary_tokens.webp
	.. image:: ./style_dictionary_tokens.webp

		@@ -0,0 +1,4 @@
		// this file creates the core.css import here all the common styles for your theme.

		// @import "./build/core/variables";

docs: create how to work with design tokens #26

docs: create how to work with design tokens #26

Uh oh!

Conversation

dcoa commented Sep 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openedx-webhooks commented Sep 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brian-smith-tcril left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dcoa Nov 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mphilbrick211 commented Oct 24, 2024

Uh oh!

dcoa commented Oct 25, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dcoa Nov 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mphilbrick211 commented Feb 12, 2025

Uh oh!

dcoa commented Feb 12, 2025

Uh oh!

ihor-romaniuk May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brian-smith-tcril left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

dcoa commented Sep 5, 2024 •

edited

Loading

openedx-webhooks commented Sep 5, 2024 •

edited

Loading

dcoa Nov 18, 2024 •

edited

Loading

dcoa Nov 18, 2024 •

edited

Loading

ihor-romaniuk May 7, 2025 •

edited

Loading

dcoa May 26, 2025 •

edited

Loading