Docs site theme switching & live token modification #1785
Replies: 2 comments 20 replies
-
|
I like this! CSS properties are incredibly flexible, so I love seeing them come into play here! I'm partial to the one-pager Bootstrap idea myself, but also wonder how complex our theming will actually get. If we're just focusing on colors, maybe something as simple as allowing users to input a palette of colors and us mapping those colors (with us adjusting saturation and lightness as needed) to the site is an appropriate solution? Not sure how complex that would get though... 😵 Also, supporting light/dark mode might be a simpler than outright theming (at least when it comes to implementation). You can do this with a meta tag in the HTML, a media query, or applying I think these rules automatically adhere to the OS color scheme settings, but need to explore that. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting I didn't know about |
Beta Was this translation helpful? Give feedback.
-
|
Adam Argyle has a good theming example using his version of design tokens for reference (it's under "4 Color Schemes"). |
Beta Was this translation helpful? Give feedback.
-
|
😮 whoa, that open-props.style library is pretty cool |
Beta Was this translation helpful? Give feedback.
-
|
If I understand this correctly, we will export a special kind of theme SCSS file from our token exporter that will look something like $alert__background-color: var(--alert__background-color);
$alert__background-color--error: var(--alert__background-color--error);
$alert__background-color--lightweight: var(--alert__background-color--lightweight);
$alert__background-color--success: var(--alert__background-color--success);
$alert__background-color--warn: var(--alert__background-color--warn);Then we will import into our doc site the full suite of design-system styles that make use of these variables, like we are doing here. (We wouldn't be importing it from a child design system. We'd always import from the core package because it happens once at build time for our one unified doc site.) We then we will also use our token exporter to generate three CSS files that define the actual values for those CSS vars but under specific selectors, like /* core-vars.css */
[data-theme="core"] {
--alert__background-color: #e6f9fd;
--alert__background-color--error: #fce8ec;
--alert__background-color--lightweight: #ffffff;
--alert__background-color--success: #e7f3e7;
--alert__background-color--warn: #fef9e9;
}
/* healthcare-vars.css */
[data-theme="healthcare"] {
--alert__background-color: #eaf8fe;
--alert__background-color--error: #fce8ec;
--alert__background-color--lightweight: #ffffff;
--alert__background-color--success: #e7f3e7;
--alert__background-color--warn: #fef9e9;
}
/* medicare-vars.css */
/* ...etc */And load them all into the document? (Or possibly that first selector is more like If I'm in the ballpark about how we'd be doing theme switching (with selectors), the only thing I can think of that this wouldn't handle is the brand-specific CSS that exists in places like https://github.com/CMSgov/design-system/blob/master/packages/ds-healthcare-gov/src/styles/components/_Logo.scss. We could import these files directly into Gatsby since each brand shouldn't be using rules that conflict with each other, but that feels like a lot of manual work. |
Beta Was this translation helpful? Give feedback.
-
|
But if we include it in our doc site under patterns, it still does exist in our codebase somewhere. Why not make it consumable? |
Beta Was this translation helpful? Give feedback.
-
|
We certainly could. I wonder where we draw the line on micro components? How might we decide to make a micro component instead of using the props of a pre-existing component? I don't have the answer and am thinking about future use cases... |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
An alternative to a component that would still capture this content in the design system package would be to ask users to access it through our translation function. It'd be something like <HelpDrawer
footerTitle={t('healthcare.drawer.footerTitle')}
footerBody={t('healthcare.drawer.footerBody')}
... |
Beta Was this translation helpful? Give feedback.
-
|
I like idea E as well and the mini component idea is good too. It seems similar to discussions I've seen on slack about adding more form fields that are pattern specific. |
Beta Was this translation helpful? Give feedback.
-
Did some more thinking on theme switching and theme modification from within the upcoming Gatsby doc site. Let me know what you think, is this valuable? I wanted to get ahead of the request if it might be forthcoming at some point.
For both options:
gatsby-source-filesystemand transform keys to css variables::root {}css descriptor at build time with Gatsby store of current theme (core, unified??, etc..) using GraphQL, each theme would have it's owndata-themereference to make switching themes as easy as updating thehtmlelement with the new data attribute.For live theme modification
reset theme,reset variableor first viewthemeModifiedto override updated variables when they have changed.For switching pre-defined themes / dark mode
Switching themes would be easy, just a matter of updating the current
<html data-theme="themeName">attribute, if there is no need to modify the current styles, localstorage wouldn't be needed.Beta Was this translation helpful? Give feedback.
All reactions