@solid-design-system/tokens 6.25.1 → 6.25.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +10 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -11,3 +11,13 @@ These tokens are exposed in two forms:
|
|
|
11
11
|
|
|
12
12
|
- **Themes** — pre-built CSS files that resolve tokens into a visual style (e.g. `ui-light`, `ui-dark`, brand themes). Themes are loaded once per page and inherited by all components automatically.
|
|
13
13
|
- **Token utilities** — CSS variables, SCSS variables, and Tailwind configuration that let you consume tokens directly when building custom components or layouts.
|
|
14
|
+
|
|
15
|
+
## Multi-theming
|
|
16
|
+
|
|
17
|
+
With Multi-theming, the Solid Design System can adapt its established components for different brands and touchpoints.
|
|
18
|
+
|
|
19
|
+
Each theme is a translation of a brand's corporate design into the Solid DS – not a 1:1 reproduction, but the closest possible approximation within a consistent, scalable system. Certain design decisions are defined system-wide to ensure quality, consistency, and accessibility across all brands.
|
|
20
|
+
|
|
21
|
+
Unlike a Whitelabel System – where each brand builds and maintains its own library from a blank foundation – the Solid DS retains a shared, opinionated base and adapts only the visual layer.
|
|
22
|
+
|
|
23
|
+
Regardless of the theme – the proven Solid DS quality remains intact. Structure, logic, accessibility, and maintainability are secured across the entire system. The theme determines how components look. The Solid DS determines how well they work.
|