Replies: 1 comment
-
Let's be careful not repeat the same ambiguous color scheme situation as before where dark themes are being used "incorrectly" (without a bigger picture intention and guidance). It is more convenient code-wise to wrap sub-areas of the UI with a scoped theme class, though I worry this might abuse dark UI where the intention is to be a global "light" color scheme. My initial thought is the concept of global theme seems more predicable. I think component-level dark UI, even with a dark color scheme such as the ContextualSaveBar, are achievable with the component-level token theming approach. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Polaris previously had the ability to theme at the component level but it was removed to increase performance and reduce complexity of managing multiple palettes. At the time this decision made sense but we have now have reasons to re-introduce this level of theming.
Allowing for component level theming would enable us to apply a dark mode to certain components instead of relying on inverse color tokens. Consumers wouldn’t need to re-apply tokens to elements. Instead they could switch the mode. We can mimic this in Figma too.
This is preferred because additionally, Inverse color roles would need to be built out of a light-mode color palette, which isn't ideal.
Additionally, the developer workflow for inverting colors is unintuitive and error prone.
For example, we invert the ContextualSaveBar to a pseudo dark mode by manually finding custom properties of internal components and overriding their values. This has caused problems in every major and some minor migrations thus far because valid internal component custom property changes don't get reflected in inverted color overrides. Also, there is a risk that inverted custom property overrides affect more than intended as we usually apply the overrides on a parent component containing many children.
Not only do we disable the stylelint-polaris errors (limiting our visibility of the problem), but the edge cases often don't get noticed until we're tophatting pre-releases in spin.
We have decided this work is out of scope for the v12 token reconciliation but we do believe this is something we will want to enable in a separate project.
Another potential use for component level dark mode theming: #10090 (comment)
Beta Was this translation helpful? Give feedback.
All reactions