Blocks: Allow users to select multiple block style variations

[ChemicalSailor]

Part of #41236.

Related: #7551, #11582

I'd like to propose that blocks can optionally support multiple block styles at the same time. Currently plugins/themes can add other styles, but the user has to select Style1 OR Style2 OR Style3 etc. I'd like to see the possibility that a user can select Style1 AND Style2 AND Style3 etc.

Take for example the table block. Currently it supports a basic no style default or striped rows. A plugin could add a styles for a header row and for a header column. The user should be able to choose to have a combination of header row, column and striped rows.

This wouldn't be appropriate for all blocks, so there would have to be some kind of 'supports' definition in the block registration.

(The table block may not be the most appropriate example because the table markup will need modification instead of simply adding more classes; this is something the plugin would have to sort out)

The alternative is the plugin adding a separate panel in the sidebar most likely using checkboxes to turn on/off header rows etc, but IMO this would be a worse UX than using block style variations.

[QuietNoise]

I support this feature request wholeheartedly. Much needed feature especially for static blocks. Right now we end-up adding tonnes of block styles to cover combination of cascading styles.
TinyMCE (styles selection control) does it already if you look for inspiration how to tackle this.

[ChemicalSailor]

Much needed feature especially for static blocks. Right now we end-up adding tonnes of block styles to cover combination of cascading styles.

@QuietNoise can you add some more detail on your use case? I'm sure it will be valuable info for anyone who looks at implementing this.

I'm not sure my example with the table block is actually that relevant, especially now there is built in support for table headers, and fundamentally it's changing the table structure, not just the style. Although it would still be nice to have the preview UX like you get with block styles. @mapk it would good to get your thoughts as you have been working on the table block.

[QuietNoise]

Use cases are any scenarios where you need to combine different styles but also allowing admins to apply each style individually.
Simple example would be to manipulate how H1 tag is styled. For example it might be in in

• in regular font, bold font, light or black font,
• it might be with regular letter spacing, with extra letter spacing
• it might have shadow, border, background image,
  or any combination of the above. This gives us 4 x 2 x 3 = 24 style options to accommodate all combinations. Quite a hindrance to ask admins to scroll through that. Add one more option would make combinations go to 48 and so on.

Alternative would to add custom controls to Heading control but as far as my experience goes it would introduce the block validation nightmare for all existing posts (due to it being a static block). Not good either.

[mapk]

@mapk it would good to get your thoughts as you have been working on the table block.

Thanks for the ping, @ChemicalSailor. It would be great to have various styles as settings that can be toggled on/off to get the right combination. We're working on adding more base styles to blocks and keeping here: #15899, #8171.

It's taking time to figure out the correct amount features and which ones we should offer as individual styles. With Gutenberg, we're going to lean more toward less options right now. We'll offer style variations to help supplement that. A long list of style options can quickly become overwhelming. Ultimately we should be relying on the themes to provide the variety of style options.

[mwhiteley16]

I would definitely support allowing for multiple styles assigned to one block. The examples provided by QuiteNoise are perfect. I, for example, have a site that has an alternate body style font, so I have added that as a block style that I can apply to paragraphs. As the same time, I have a block styles that assign a max-width for paragraphs, it would be nice to assign both styles at the same time so I have max-width and alternate body style, without the need to create another block style for max with AND alternate body style.

[niaccurshi]

I hope this can be progressed into reality because as @QuietNoise references, if we have blocks that could do with multiple combinations of styles it is much easier on the end-client to be able to toggle those on and off as needed rather than to have specified styles for every, exponentially building, combination.

A use case from work I'm doing today, adding styles to a "group" block:

• Styles to constrain the width and padding of the group (4 options)
• Styles to change the top and bottom padding of that section (2 options)
• Styles to change the background of the group (5 options)
• Styles to add a decorative divider (1 option, if not counting the "off" state)

This becomes unmanageable very quickly, and so I will have to continue with only using css classes in the advanced options which, unfortunately, are not very friendly for the end client.

Ultimately this doesn't need to be something that happens as default but would be greatly appreciated if there was at least the option of creating groups of styles as a developer that would form their own, distinct, groups of styles to pick from. Something like (rough example)...

wp.blocks.registerBlockStyle( 'core/group', {
    group: 'Padding styles',
    styles: { [
        name: 'large-vertical-padding',
        label: 'Maximum padding'
    ], [
        name: 'small-vertical-padding',
        label: 'Minimum padding'
    ] }
} );

[strarsis]

Yes, adding stylistic options to a block quickly results in very large numbers of block styles for all combinations. My current workaround is to let the theme add block options that just toggle some has- CSS classes. This requires to add JavaScript/React-code that also break sometimes. Combinable block styles are much better because the theme designer can just get the job done and doesn't have to add custom UI stuff.

Additionally, it would make sense to add the ability to group block styles, like it is possible with blocks because the number of block styles for just one particular block (notably group, heading, paragraph) can grow substantially.

[ragudesign]

I agree with this solution. I added my own custom testimonial block and i need to add so many style variants as i can only pick one style. @niaccurshi suggested a very good solution, this way we can create a style group, let's say 'Border Style' and from there you can select either a dotted border or straight line. And add another style group for 'Background Style' where the user can select a pre-defined background. At the moment you need to create a style with let's say dotted border with blue background, dotted border with green background etc.

[4mation-roger]

+1
ran up against this limitation today

[reedcodes]

I also have a need for this. I am adding block styles through my theme, using options I don't want to include in my other theme, and my block has two border styles and six background styles. It would be much easier to code and maintain if these could be grouped into two different block style groups, rather than adding one block style declaration with 12 block styles.

[strarsis]

Yes, the cascading nature of CSS would be something very useful here!

[unprintedch]

This what we need, for example the button:
I have options like simple, tiny, icon etc... that are all cumulative of course.
I add those via custom class. If i could provide the editor with a UI to choose these classes! It would be a dream comes true.

[strarsis]

+1! HTML and CSS already support multiple classes per element since the beginning of the web. The UI for block style selection has to be adjusted from being radio-button like to checkbox-button like and toggle the associated is-style- classes.

[richrd]

If there was someone to write a PR for this, would it potentially be accepted as a feature?

[strarsis]

@richard: Yes! This would be great. I am not good enough with React + Gutenberg to write something like this.

[skorasaurus]

+1 not so much for myself this would be a big roadblock for anyone who wishes to atomic CSS in Gutenberg.

[richrd]

I just setup a development environment and I'm taking a look at how this could/should be done. I assume this is where most of the changes need to happen https://github.com/WordPress/gutenberg/blob/master/packages/block-editor/src/components/block-styles/index.js

Anyone got any pointers on what to look out for as I'm not yet familiar with the gutenberg code base?
What things might break and need fixing if a block has multiple active styles?

[strarsis]

My 2 cts: There is a preview selection UI thing used for the block style selection. Does that UI control already supports the selection of multiple items?

[richrd]

@strarsis Excellent point! I bet it doesn't but I'm not sure it would even be logical that way. I think each style preview should only show what that specific style does to the block. That way they only represent what they do on their own. The combined effect of multiple block styles should be shown in the editor but IMO not in the block style preview.

[strarsis]

@MrWeb: That's nice! I also would have an use case for this.
The user can select wavy-shaped group blocks. And then further specify in what direction the wave will go and what transition (splash; droplets; etc). Having a second block style selector just for this helps a lot with keeping the number of possible combinations low.

[nickfmc]

I do love that idea of Style Groups, but I would still also love a modifiers too that could just be a set of true false toggles that are all classes that can work together no matter on or off. Things like the WP columns block, I'd have Modifiers: no gutters/stack early/swap order on mobile , etc. these are are things that could all be added or none be added. This is the main reason developers are currently using 3rd party plugins to replace something that is perfectly fine but we can't have our clients remember a bunch of classes.

[mrwweb]

@nickfmc Your needs make a lot of sense. They also make me think of #15077 and #19367 as possible ways to handle that.

One thing I notice about your example is that the three modifiers might be just as appropriate (or better?) as 3 toggles instead of block styles since they don't have obviously unique visual previews or even impacts when editing (except for gap). Making registration of other block settings and attributes easier and faster (especially those that just toggle a class) feels like it might be even better as a new issue. (Just thinking aloud here.)

---

@MrWeb Looks like @strarsis forgot a "w". 😃

[nickfmc]

@nickfmc Your needs make a lot of sense. They also make me think of #15077 and #19367 as possible ways to handle that.

Ahh yes, those would be very similar use case for sure and both would make sense for the issues I see with my clients. I was just thinking toggles to allow more of a description of what they do, giving you a ? to hover or something but ya basically just comes down to more class options.

[jasmussen]

Coming back to this one here, I have a feeling (please correct me if I'm off base) that the need for multiple block styles is related to the current behavior where each style variation also adds a CSS class you can attach your custom rules to. Paired with the interface being rather prominent at the top of the inspector, I can see this being an easy way for a dev to add convenient style shortcuts that go beyond what's baked in.

If that's the case, I think there may be an opportunity to lean into that specific use case, and augment the existing interface that exists for adding classes, the one in "Advanced":

• With the incoming split inspector (Split block tools between "settings" and "appearance" #40204) there's less reason for "Advanced" to be collapsed and de-emphasized
• Just like how tags have auto-complete, a similar interface could be explored that would add class "chips", and let you search for classes already applied.

I'd love to see some great designs for improving that class interface, and making it all the more ergonomic to use. There's no reason it can't be as easy to use as the style variation panel. Embracing this as the UI for it would also avoid the pitfalls of the style variation UI, where you'd be able to apply styles that were designed to be mutually exclusive, such as Solid and Outlined, as well as the race condition headache where you'd have to decide which box-shadow would win, if two styles both added them.

On a separate note, style variations were recently made user customizable (#47138). Ultimately this can lead to a cool use case where a particular applied button style can be changed across blocks by simply editing the source variation in the style UI.

[shoelaced]

Just ran into a scenario where this would be extremely helpful and I think @mrwweb's solution is a good one. Given the concern about a cluttered panel experience, I wanted to add that unless I'm missing something and it's possible already, it would be great to include a styles_per_row attribute to the style group registration. In my particular case, I could set it to a single row of 5, since the style involves small icons and the preview gives a larger view anyway, which would be much less cluttered than the 5 giant tiles at 2 per row that take up helf the panel as I'm getting now.

[mrwweb]

I have a feeling (please correct me if I'm off base) that the need for multiple block styles is related to the current behavior where each style variation also adds a CSS class you can attach your custom rules to. Paired with the interface being rather prominent at the top of the inspector, I can see this being an easy way for a dev to add convenient style shortcuts that go beyond what's baked in.

I'd put the emphasis on "prominent" and "convenient". In my opinion, the two "killer features" of the styles interface are:

• Discoverability (closely related to "prominence" but slightly different)
• Autopreviews (some of that value has been diminished since the interface was changed to only show previews on hover)

That discoverability piece is what I would worry about with the Custom CSS Class path, but I do wonder about something like the classic "frequently used tags" type interface except controllable by developers. Even then though, I wonder if something like a toggle-able checkbox would be easier to use than an "add/remove" interface, since it's easier for users to test how something looks with a toggle rather than adding something to a box above, moving the mouse, and removing it.

[cbirdsong]

The idea of a developer-controlled list of CSS classes is a potentially interesting feature that would be worth exploring, but I agree that it isn’t really equivalent to the block style system as it exists today or the expanded functionality originally proposed in this issue. The “Advanced” panel in the sidebar does not seem like the place for it or something similar.

[nickmatternow]

there are also plugins that take care of developer classes for gutenberg now too if someone needs this functionality

https://dplugins.com/downloads/plain-classes-gutenberg/

[bongojules]

Just to say I'd also massively appreciate this feature - Especially @mrwweb's proposed implementation of "Block Style Categories"

Will be super useful for sure.

[hanneslsm]

Can we please get some traction into this issue again?
It would open up immense possibilities, especially if it would be possible to have different categories (e.g. Search block: Category 1: With Label, Category 2: Button inside, Button outside, etc. #51617 (comment))

[kauaicreative]

Toggle style variations on and off e.g. checkbox - not radio.

[justintadlock]

I've given a lot of thought to this recently. There are definite problems with just allowing any block style to be combined. These, particularly more complex styles, will often clash and create a poor user experience.

At the same time, there's an obvious need for theme authors to be able to add multiple CSS classes to a block and present them to users through an easy-to-use UI.

And that is 100% already possible. The problem is that there's no documentation around doing that. That's where I believe the biggest change needs to happen before we explore changing the core block styles system.

I plan on running a tutorial series on the WordPress Developer Blog showing how to do this. Here's the discussion link: WordPress/developer-blog-content#130

If you have feedback on multiple block styles/classes that you want to add to that discussion, please do so. My plan is to begin writing the guide next week.

[strarsis]

Naturally, CSS classes can also be combined. Sure, blocks and block styles are a higher level abstraction than CSS classes, but both allow combining things - and also allowing the theme developer to add exceptions or exclusions for specific block style combinations.

[cbirdsong]

The custom controls you have in that issue are definitely worth writing up as a guide, but it seems like there's still space for a simple way to have multiple variations on block styles. Anything involving adding custom controls and/or a build process is a massive step up in complexity from register_block_style/ registerBlockStyle and would also be more likely to break with future editor updates.

[acketon]

I've given a lot of thought to this recently. There are definite problems with just allowing any block style to be combined. These, particularly more complex styles, will often clash and create a poor user experience.

At the same time, there's an obvious need for theme authors to be able to add multiple CSS classes to a block and present them to users through an easy-to-use UI.

And that is 100% already possible. The problem is that there's no documentation around doing that. That's where I believe the biggest change needs to happen before we explore changing the core block styles system.

I plan on running a tutorial series on the WordPress Developer Blog showing how to do this. Here's the discussion link: WordPress/developer-blog-content#130

If you have feedback on multiple block styles/classes that you want to add to that discussion, please do so. My plan is to begin writing the guide next week.

@justintadlock I look forward to your documentation with great interest. That documentation will be very welcomed for a project I'm working on this year. I think that adding new controls to blocks from a theme is a good option in the short term, but I still agree with others here that Block Styles should be expanded to support multiple active styles at the same time. Block Styles are so simple and accessible for Theme Developers that may not be comfortable with more advanced modifications to a block. Being able to think of block styles in a more component based system approach instead of the mess it can become now would also really help with the bloat and CSS issues faced on the theme side.

Like @cbirdsong mentions above, I too worry about custom built components breaking between WP upgrades. I deal with that now for our existing Block plugins and it is a constant issue for us. I'd prefer to avoid that and leverage Block Styles as outlined earlier in the comments by @mrwweb and others by supporting categories or some sort of flagging system for each style to denote if it can be mixed with other styles or what styles it can be mixed with.

[tresorama]

Having multiple block styles slot will make developer life easier.
They let use Gutenberg Blocks as React/Vue/Svelte component, because "Block Style" can be seen as component props, that simply add a CSS class to the element.

So dev can create CSS classes system using a BEM approach and with not much code/time we will have a native user friendly way to add "variants" to component.

It also remove the complexity to use React just to expose a "radio/select", and gain the auto visual preview.

[zkingdesign]

Really looking forward to this, it's a natural step in the right direction, I've came across needing this more and more while developing themes recently.

[OlaIola]

I've stumbled upon the same need. Block Partners and block Organizers are pretty much the same. So, I want to make one as a variation from another but limit each version to one per page, but right now, if multiple is false, I cannot add Organizers if I have Partners added. I need them separately due to the IDs (anchors) I am using, and I don't want to allow users to fill them in themselves, IDs will be missed or messed up.