Allow theme authors to opt out of color and typography preset autogeneration in WordPress 6.6

[ndiego]

Description

WordPress 6.6 is on the horizon, and with it comes the ability to create color and typography presets in the Site Editor. While the feature has many great use cases, not everyone will want to use this functionality. The problem is that color and typography presets are autogenerated based on any existing style variations registered with the theme and the theme's main theme.json file.

This is fine as a default experience, in my opinion. But there are cases, especially when the theme author has built very sophisticated style variations, when autogenerating presets is not ideal. I can also see this feature not being wanted in heavily curated environments like client sites. There needs to be a way for theme authors to opt out of this experience.

I believe that we need an opt-out mechanism in place before the release of 6.6, and the lack of an existing solution is why I have labeled this ticket as a bug.

Possible solution

Add a new property to theme.json (and any style variation JSON file), something like generatePresets, that defaults to true. Presets would be autogenerated by default, but this property would allow you to do two things:

• Opt out of the experience entirely (set "generatePresets": false in all JSON files)
• Selectively opt-out specific style variations and curate the presets that are generated and displayed to the user.

Step-by-step reproduction instructions

1. Use Gutenberg and TT4
2. Navigate to the Site Editor → Styles and you will see the autogenerated color and typography presets

Screenshots, screen recording, code snippet

Environment info

• Gutenberg trunk
• WordPress 6.5

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[bacoords]

+1 - I haven't seen this, but is there a roadmap for the composable presets feature? What properties beyond typography/color will eventually be covered, etc?

The ability to let theme builders opt out until they've been able to confirm it's a good experience for their users would be great.

[fabiankaegy]

Yeah I agree that exposing the parts that make up a style variation is in theory a great feature that I actually really appreciate for certain usecases. But it does come with the issue that it breaks some governance models we started to build using block style variations.

When working on highly customized client projects we often use theme style variations for different sub brands. These brands have different corporate design guidelines that define how the color/type, etc, should be combined. Up until now this was actually one of the nice features of the style variations. They allowed you to define strict style bundles that could be enabled one by one.

Splitting out the individual parts of the style variation means that I could now use the typography of brand 1 with the colors of brand 2 which is not desirable.

[bgardner]

I agree that allowing theme authors to opt-in/out of this feature is ideal. As @ndiego points out, there are themes which offer several (elegant) style variations, yet the user experience of seeing those colors might not reflect that elegance. I do appreciate the auto-generation, though, because with themes such as Powder (see below) the user experience is much better because of the simplicity of the the variations (color only) and the way all of them are presented:

[bgardner]

Worth noting #60478 is more relevant, should this opt out take place.

[richtabor]

If the site have variations available, why wouldn't you want color/typography-only variations? I'm not following how you'd want one, but not the other. And if you don't want style variations, you wouldn't get the color/typography-only variations.

[richtabor]

As @ndiego points out, there are themes which offer several (elegant) style variations, yet the user experience of seeing those colors might not reflect that elegance.

@bgardner Do you mind clarifying here?

[ndiego]

If the site have variations available, why wouldn't you want color/typography-only variations? I'm not following how you'd want one, but not the other. And if you don't want style variations, you wouldn't get the color/typography-only variations.

You might want both, you might not. Perhaps you want to register style variations with multiple color presets for users to choose from, but you don't want them mixing and matching typography due to specific typography settings set in each variation.

My problem is that, with the current implementation, you have no control over the autogeneration process as a theme author. This is essentially an Editor curation issue.

If you register multiple style variations, you always get color/typography-only variations along with them. I'm happy with this being the default, but I would like to be able to disable it at the JSON level if I want to.

[bgardner]

Do you mind clarifying here?

@richtabor Just saying that for a theme such as Reboot, the experience for users might be received better with this:

Than with this (which currently doesn't even have tooltips to give context as to the palettes):

[bgardner]

AFAIC, it’s less about which way is subjectively "better" and more about (until a strong user experience is provided) giving theme authors the choice in the meantime.

[carolinan]

I agree that theme developers needs to be able to decide what their style variation should show as, and the .json style variation file is the best place to add a property used to control it.

[carolinan]

Aside: If the existing style variations are only color and typogrpahy presets, is the single preview of the default style at the top of the panel needed? Or should there be a reset in actions menu?

[ndiego]

To better articulate why I think an opt-out mechanism is needed, I threw together a fictitious theme for a business owner who likes to update their site based on the seasons. They have a dedicated style variation for "Summer" (default), "Fall", "Winter", and "Spring". Each style variation has its own colors, and the "Winter" version has a stylized font. In the video, I walk through why this business owner might want to opt out of generated color/typography-only style variations for their site.

style-variations-walkthrough.mp4

[richtabor]

I think we should not have colors and typography abstracted from variations, if we're considering an opt out. Otherwise we're fragmenting the user experience (i.e. you can get some colors, sometimes).

[bgardner]

Personally, I'm ok with the way things are (because Powder's UX is just fine with the new functionality). My support was mainly in favor of providing options for theme designers, but one could easily make the argument that they (as I did with Powder) need to make adjustments (not necessarily concessions) to accommodate the new functionality.

[justintadlock]

I think we should not have colors and typography abstracted from variations, if we're considering an opt out. Otherwise we're fragmenting the user experience (i.e. you can get some colors, sometimes).

I think that would be the best route, which is how I thought the originally proposed feature would work. That path would give far more flexibility and control to the theme designer in deciding how things should work.

[richtabor]

Color-only and typography-only variations are good to go, and should still be filtered as they are currently in Gutenberg. There wouldn't be a change to Powder as it is with the latest Gutenberg version.

I'm proposing we don't split the colors and typography from full theme style variations.

[ndiego]

I'm proposing we don't split the colors and typography from full theme style variations.

Perfect. If we don't split out the presets from full-style variations, there is no need for an opt-out mechanism. This still allows theme authors to register color and typography-only presets, as in Powder, which is fantastic. 👌

[ndiego]

Side note, we may want to consider updating TT4 alongside 6.6 with a few additional color and typography-only presets to better show off this new feature.

[bgardner]

Group hug? 🤗

[annezazu]

Just chiming in to say thank you for sharing this feedback early <3 and that I'm going to update the Source of Truth, this prior core editor improvement post on the topic (will have a changelog), and the help test 6.6 features post

[carolinan]

Side note, we may want to consider updating TT4 alongside 6.6 with a few additional color and typography-only presets to better show off this new feature.

Please remember to open a new Trac ticket as soon as possible if that is the case, since this would be an enhancement and we are already past Beta 1.

[mtias]

There was a bit of a disconnect here between the original spec and the eventual implementation. The simplest approach is to let the contents of the variation determine the outcome, which avoids the need for any opt outs and fragmentation. If a variation is registered only with color settings or only with typography settings, then those are presented as distinct presets, otherwise nothing changes. The intention is clear and respects bundles as bundles. If a variation is created defining both colors and typography—the current state of style variations—it continues to be presented as a style bundle.

It'd make sense in further iterations to allow themes to express bundled styles as the composition of color and type variations via reference, not duplication, but that's for another day.

[richtabor]

Please remember to open a new Trac ticket as soon as possible if that is the case, since this would be an enhancement and we are already past Beta 1.

Is this something we can achieve @carolinan?

[scruffian]

f a variation is registered only with color settings or only with typography settings, then those are presented as distinct presets, otherwise nothing changes.

I have a PR for this here: #62469. This only partially addresses the original issue - for example TT4 has a color only variation called Onyx which will now be removed from the style variations panel.

[mtias]

@scruffian that's fine — if it only defines colors it's already confusing to see it in a style card that includes a representation of typography, even though it doesn't bundle any type styles.

[luminuu]

+1 for this, I've created a video that walks through the current changes with another theme explaining how the different user experience is with the current way it's working: https://youtu.be/U0q0G5wA52U

[annezazu]

With this PR merged, I believe the main approach that this issue seeks to have addressed has been resolved and am going to close this out: #62469 Happy to reopen if folks think otherwise.

What remains to be addressed is a separate discussion for whether someone creating a color or typography only variations should be able to have it surfaced at the style variation level. As Matías notes above, this does create some confusion when it's represented at the style variation "level" when it's only impacting one piece of the experience, especially with this new option now available. @luminuu video shows the impact of this change going from 8 style variation options to 1 when the variations only have color options. The answer to this is likely more about ensuring clarity in block theme documentation about where things will show up going forward rather than changing things further. cc @justintadlock as I know you've done a lot of work there and this will be a change for theme authors to adjust to, depending on how they have approached style variations.