-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Colors and typeset variations from theme style variations #56604
Comments
I started some exploration here: #56622 |
@scruffian what do you think about following up #56622 with this? Where color-only and typeset-only variations are added as presets, not as full variations. |
How should this work? We could just filter out variations that only contain colors / typography? |
Yes, I think so. |
This is now completed. |
This is a proposal for a mechanism that would allow style variations that are tailored for colors and typesets rather than entire designs. It's common for themes to want to offer alternate colors but without other design modifications. It's also an important consideration for enterprise setups, where smaller units of brand settings need to be passed through to different pages, templates, or sections.
Being able to express a reduced subset of
theme.json
can help with maintainability and composability. Instead of new API mechanisms for multiple color sets (like #48581 proposes) this instead suggests relying on the same theme.json structure of style variations but determining the relevancy based on what options are actually set.For example, a registered style variation that only modifies color properties and sets color palettes would not appear as a "browse styles" set but instead become a color preset directly tied into the color panels.
Example:
Such a set would show up to be selected within the "colors" tab in global styles and other relevant interfaces. Themes could register alternate palettes without forcing the "browse styles" UI which aggregates and assumes changes to virtually anything.
The UI representation can thus be paired down to just alternate color sets.
Likewise, font pairs or single font typography scales that apply throughout the design can be defined as simple json variations that only touch
typography
properties.Example:
This would offer type selection at a global level within Styles > Typography.
There are multiple advantages to leaning on a single file structure, particularly as we embrace section specific json files with a higher composability expectation. This expression could allow alternate color palettes for different contexts easily.
The main question is whether the initial performance impact of determining whether properties of a specific kind are being used is a deterrent. Alternatives can include introducing a "type" or some sort of flag as a top level property. I think it'd be nice if we could avoid that.
The text was updated successfully, but these errors were encountered: