-
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
Themes should be able to offer "packages" of complementary color options #39028
Comments
Just checking, but are these "packages" a separate train of thought from style variants (other theme.json files within a theme)? Or are you just referring to the controls themselves? |
The impression I had gotten was that style variants were sitewide palette swaps, and packages would be available on every block. "Presets" might be a more clear name for them, as they would only use options already registered with theme. Practical example for colors: When selecting a block and opening the color panel, a user would first see the theme's defined packages/presets to choose from, in addition to a "custom" option, which they could use to access the currently existing controls. Extremely hasty mockup1: Registering this set might look something like this: "color": {
"palette": [
{
"name": "Black",
"slug": "black",
"color": "#000000"
},
{
"name": "White",
"slug": "white",
"color": "#ffffff"
},
{
"name": "Lavender",
"slug": "lavender",
"color": "#fdeffd"
},
{
"name": "Pink",
"slug": "pink",
"color": "#c73271"
},
{
"name": "Purple",
"slug": "purple",
"color": "#2a062d"
}
],
"packages": [
{
"name": "Base",
"slug": "base",
"options": {
"text": "black",
"link": "pink",
"background": "white"
}
},
{
"name": "Aside",
"slug": "aside",
"options": {
"text": "black",
"link": "pink",
"background": "lavender"
}
},
{
"name": "Highlight",
"slug": "highlight",
"options": {
"text": "white",
"link": "lavender",
"background": "pink"
}
},
{
"name": "Dark",
"slug": "dark",
"options": {
"text": "white",
"link": "lavender",
"background": "purple"
}
}
]
} (Also, I guess 5.9.1 changed the way the color panel looks? My screenshot from earlier today was somehow already out of date.) Footnotes
|
👋🏼 This seems to match what's being explored here #48581 and here Mind if I close this out as a result and we can consolidate the discussion going forward on these more in progress, related items? |
Sure! |
What problem does this address?
For novice users, the color panel is getting pretty overwhelming:
For advanced users, it's easy to make a mistake when customizing a block to match another part of the site, leading to design inconsistencies.
The typography panel faces the same problems.
This issue can be somewhat worked around by using block styles or block patterns, but block patterns can't be applied to existing content or updated after the fact, and block styles can't be customized after they're applied without forethought and CSS trickery on the part of the theme author.
What is your proposed solution?
Themes should be able to define "packages"1 that apply a set of typography options (font family, font weight, line height, etc) or color options (text color, background color, etc). Typography examples might be "subhead", "display" or "eyebrow", and color examples would be stuff like "spotlight" and "alert" or even simply "light" and "dark".
On supported themes the typography and color panels would be replaced with a list of packages, along with a "custom" option2, which then reveals the full color or typography panel as it exists right now. This way, users could easily change the look and feel of a block without having to dig into the full typography and color panels to set all relevant options individually.
Ideally, packages would be applied to blocks in a way that allows the theme author to update a package that apply across existing content using the package, rather than the package simply acting as an alias for setting the color/typography options, which then hard-codes the values into the block.
It also might be worth considering if packages should be something that an advanced user could create or edit themselves, which would bring a lot of power and flexibility previously only available to theme authors.
Footnotes
Alternate name suggestions welcome. ↩
Themes should also be able to disable this custom option from appearing. ↩
The text was updated successfully, but these errors were encountered: