Allow creating and editing custom block style variations in Global Styles

[tellthemachines]

#46343 added the ability to edit block style variations in Global Styles. That was only part of the scope of the initial issue (#44417), but further steps required a few changes to be made to the global styles APIs. Now that #47098 is done, it should be straightforward to add new variations from the global styles UI.
Also, given the addition of per-block custom CSS in #46571, we could consider:

• adding a custom CSS field to block style variations, which would open the door to
• making custom block style variations editable. Even if custom styles are added via a stylesheet instead of theme.json, having a custom CSS field would allow for easy overrides.
• it should also be possible to add custom block style variations via theme.json.

[annezazu]

Noting that "needs design feedback" has been added to this issue and it's been added to the "Needs design" column. While there are designs on the original issue for development to get started, it's advantageous to have design reviewing once more with how much has evolved around 6.2. Leaving this for coordination purposes @WordPress/gutenberg-design as development will start but will need assistance.

[SaxonF]

Once this branch is finished we might be better served using the same variant interface as what's found in local styles so that it's familiar.

[carolinan]

it should also be possible to add custom block style variations via theme.json.

Should this register a new style variation? Or would it still require register_block_style()?
If it could be done via theme.json only, developers may be able to remove more PHP.

PR for outputting the CSS:
#49396

[jasmussen]

Here are two mockups that expand on Saxon's sketch above (and Saxon please feel free to correct anything in the Figma if I missed a beat).

Just as orientation, an ellipsis menu in the Styles panel could take you to where those variations are managed, i.e. Global Styles:

Once there, styles would be edited just as Global Styles → Blocks are:

Note that the above mockup shows using the regular panels instead of the drilldowns. I could go either way on this, but such a change should likely be implemented separately if need be; the main point is to edit a variation as if it were a block in Global Styles.

[SaxonF]

@jasmussen with #49428 the global view will be consistent with the local view, so the thought was the variant selection / modifying should also work the same way. ie no drill down. You just select the variant as you do in local, then make any changes. Clicking the plus adds a new variant.

add-variant.mp4

This way it's also consistent with how you could make local changes and "push to global" if a block has variants.

Obviously this means 49428 has to land first so will spend some time on that this week.

[jasmussen]

Oh cool, thanks for sharing that video. I've personally not too strong an opinion on whether we do the ItemGroup + Drilldown or the "style buttons as tabs", so I suppose implementation wise the path of least resistance can be chosen. Thanks Saxon.

[carolinan]

Please reconsider the horizontal buttons with the block style names. It is difficult to use them when the names are truncated.
I will share the issue where users has left feedback about these buttons, once I find it 😬

[jasmussen]

For what it's worth, the style of those buttons could be explored and improved independently of their behavior of acting as tabs in this state.

[jameskoster]

I don't have a strong opinion either, but we probably need to think about variation actions beyond create, e.g. delete, duplicate. With the itemGroup approach that could easily be handled in a more menu:

I find it trickier to see how this would work with the button approach. Did you have an idea @SaxonF?

[paaljoachim]

I have revisions in the back of my mind right now. This PR: #46667
Let's say that we have a method to seeing what was adjusted in a revision. We could transfer the same method over to viewing a style variation. As a specific style might be made up of various adjusted settings.

In this case it would mean seeing an overview of style variations and then clicking these to open these up to show what they are made up of. Seeing each individual setting and value which makes up a specific style variation. Perhaps similar to what James shared here: #37037

It would create a consistent experience in viewing an item. Be it a revision or a style and perhaps other items which are made up of smaller pieces.

[SaxonF]

Is there a case where we use ItemGroup as a selection mechanism? It seems its generally reserved for listing items like elements and revealing more about them via drill down or popover.

What about following a pattern similar to Keynote and Figma by using a Dropdown/Select?

variant-selection.mp4

For what it's worth, the style of those buttons could be explored and improved independently of their behavior of acting as tabs in this state.

I agree with @jasmussen here that we could pull variation selection out into its own issue, possibly grouping with a "delete variation" action.

[oandregal]

#49827 is experimenting with the API for registering/unregistering style variations from theme.json (no UI, just being able to control style variations lifecycle from the theme.json).

[jasmussen]

Let's unstick this. It seems like the outstanding feedback is whether to use ItemGroups or a dropdown or something else, but the remaining pieces of these mockups are solid. Is that right?

If yes, then I'd like to update this issue and move it to a dev. The ItemGroup is already widely in use in Global Styles, so if we want to move to something else that seems best to create an issue for separately, and then do it in one fell swoop:

[fabiankaegy]

Hi all 👋

It's been a wile since this issue saw any movement. Is there anything one can do to help move it forward?

The ability to define block style variations that actually use the underlying block settings instead of just a custom class name is soooo valuable and it would really help us implementers by having to build way fewer completely custom block extensions to achieve a similar result :)

[unscripted]

It's been a wile since this issue saw any movement. Is there anything one can do to help move it forward?

I want the full functionality that @tellthemachines defined in this issue. However, as defined, feels a bit more like an epic.

I view this as four potential "features" where some focus on providing the support to the developer others open it globally via the UI.

1. Add ability to style custom variations in theme.json.
2. Add ability to edit/save custom variations in the global style editor.
3. Add ability to register custom style variations in theme.json.
4. Add ability to create/delete custom style variations in the global style editor.

IMO, this should start by supporting the developer with adding support to style custom variations in the theme.json that are registered via register_block_style in PHP or wp.blocks.registerBlockStyle in JS.

[aaronrobertshaw]

Hi @unscripted 👋

Thanks for the feedback!

The four features you outlined are definitely on the radar for block style variations. To varying degrees, features 1-3, are being worked on as a means for providing easier styling of sections.

I'm not sure if they'll make it into WP 6.5 but you can follow the latest on this section styling issue and some of the related PRs:

• Theme.json: Extend block style variations support #56540
• Block Styles: Extend block style variations as mechanism for achieving section styling #57908
• Theme.json: Allow shared block style variations via separate theme.json files #57787