docs: dark mode #2054
docs: dark mode #2054
Conversation
|
✅ Deploy Preview for red-hat-design-system ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Size Change: +544 B (+0.26%) Total Size: 208 kB
ℹ️ View Unchanged
|
|
Opinion here: I feel like in order to make this really viable we need full theming css layer. Instead of the switch swapping between |
|
I'm not entirely sure what you mean by full theming css layer, so let me describe what I think you mean, and respond to that. If I got it wrong, let me know. The way most sites do this is by toggling a class name or attribute on the body, for example shoelace uses So if we were to do such a thing, we'd add some hypothetical While that's a good approach for most sites, it runs contrary to the principles of theming in RHDS. In our design system, theme and color palette are two different things. When discussing RHDS, "theme" means customizing one or more color palettes. When we think about it that way, what need does the design system docs site have to customize the theme, outside of pages which provide examples of how to do so? Wouldn't that be confusing, a bait-and-switch? Rather, we should strive to make ux-dot an exemplar of our HTML-first approach to design systems engineering. In most cases the user of our design system (i.e. the page author) should get most of the utility of the DS from HTML tags and attributes. Occasionally, they may use CSS to customize designs (e.g. for a particular pattern or to implement a custom theme) and rarely they should use JavaScript APIs to provide interactivity (e.g. to toast an alert). The "big idea" of dark mode / theming / color palettes in RHDS is that authors who just want to use the sane defaults shouldn't have to write CSS or JS to get them. |
I could have been clearer. By theme switch I mean utilizing our theme approach alongside of prefers-color-scheme which is IMHO the basis for a switch of light and dark directed by user preference for the whole page. This then is an additional layer on top of what we have already with custom themes + color-palettes. We are maybe saying the same thing here or closer than we think. To help demonstrate here is a fast and dirty code example https://codepen.io/zeroedin/pen/NPKGmWp of how I would expect this to work. ( I also realize components used outside a surface like the switch in this example aren't set to the proper context here, same rules apply using a component on a static background until we get style queries)
|
|
This PR already supports prefers-color-scheme (testing instructions point 5) |
What I did
Screencast.From.2024-11-18.08-02-16.mp4
Testing Instructions
Notes to Reviewers
icons and ux of the switch are TBD