I’ve been talking about block styles a lot lately, and I’ve got more to say!

Block Styles are Super Useful

Editing a web page should be as easy as possible. That sounds obvious, but it requires real thought, attention, and experimentation to find the best ways of guiding and empowering site editors.

The WordPress Block Editor has made editing much easier in many ways by providing tools that instantly show editors the impact of their choices. Block Styles is among my favorite of these tools.

With just a few lines of PHP code, I can define a new Block Style and then use CSS style it. It is fast, powerful, and user-friendly.

register_block_style(
	'core/list',
	array(
		'name'  => 'useful-multicolumn',
		'label' => 'Multicolumn',
	)
);

However, there is one huge limitation of Block Styles. You can only select one style per block.

Many folks have requested the ability to use multiple block styles together, myself included, but that’s a potentially complicated request. It’s complicated because one can’t assume every Block Style can be combined with every other one, and letting editors configure incompatible design options isn’t a very good experience. For more background, read the overview of reasons for and against supporting multiple Block Styles in “Should Users Be Able To Select More Than One Block Style?” on WP Tavern.

A Perfect Use-case for Multiple Block Styles

I was recently building a site with an absolutely beautiful brand that included masked images with colorful paint strokes behind them.

The moment I saw this design element, my mind went straight to block styles and the one-style-per-block shortcoming. Ideally, I wanted to let users combine a choice of image masks AND brush stroke design. If I provided 5 masks and 5 brush patterns, editors could make 25 unique combinations for any photo they added to the site.

I had run into almost this exact issue before, and I did not want to use the same workaround of providing 25 block styles—one per unique combo—again. The list gets long, and it’s hard to experiment with that many options.

Implementing My Own Second Block Styles Interface

Since I’ve been looking for ways to learn more about customizing the Block Editor, this new need was my chance to dive in deep and try to provide the best possible editing experience. With big kudos to “A Crash Course in WordPress Block Filters” on CSS-Tricks, I added a new set of options to the block sidebar that let editors make their own combinations of masks (with Block Styles) and brush strokes (with a new custom option).

I next wanted to make the custom options more visual like block styles, so that editors could see their choices rather than read a description of them. I added some CSS to make each radio button in the brush stroke option show the stroke it would apply.

This gets me really close to having two sets of block styles that can be combined! I think the editors are going to love it, and I’m proud to have built it and be able to share this with others. (Yay open source knowledge.)

Here’s what it looks like in action!

But that doesn’t mean there isn’t…

Room For Improvement

Both the image masks and brush strokes use about the same amount of CSS to style the images. However, the amount of code required to create the two options panels is WILDLY different.

The image masking block style was registered in 12 lines of PHP like this:

/* Images */
$blocks_with_masks = [ 'image', 'media-text', 'cover' ];
foreach( $blocks_with_masks as $block ) {
	for( $i = 1; $i < 6; $i++ ) {
		register_block_style(
			"core/{$block}",
			[
				'name' => 'mask-' . $i,
				'label' => esc_html__( sprintf( 'Cutout #%d', $i ), 'collective' )
			]
		);
	}
}

That’s slightly more complicated than a normal single block style, but it says: For the Image, Media & Text, and Cover blocks, create 5 mask styles called “Cutout {1-5}”.

The brush stroke options, on the other hand, required ~150 lines of JavaScript, ~50 lines of PHP, and a stand-alone build process all stored in a custom plugin. Even if building this wasn’t a learning experience, the difference in time required to code each would still have been measured in multiples. And even then, the interface for selecting the brush strokes is still inferior since it doesn’t include real live preview incorporating an image with the brush stroke options applied, something that Block Styles does automatically.

Proposal for Improving the Block Styles API

So after having gone down this path and considered the arguments for and against multiple Block Styles, I’m still in favor of making it possible, because the alternative is so much more time consuming. However, I do see the need to to let developers define which styles can be combined.

Based on my own experiences using them, I think the best path forward is:

1. Introduce a new concept of “Block Style Categories”
2. Only allow an editor to select of one Block Style per Block Style Category

(I see I’m not the first to suggest this either.)

Since Block Patterns already have a similar concept of categories, using the same API pattern would make sense:

/* ⚠⚠⚠ THIS FUNCTION DOES NOT EXIST ⚠⚠⚠
  It's only a proposal */
register_block_style_category(
	'my-style-category',
	array( 'label' => __( 'My Style Category', 'mytextdomain' ) ),
);
/* This is a real function, but the 'category' attribute won't have any impact right no */
register_block_style(
	'core/list,
	[
		'name' => 'my-style',
		'label' => __( 'My Style', 'mytextdomain' ),
		'category' => 'my-style-category' // optional! defaults to a general category
	]
);

A new register_block_style_category function and a category argument for register_block_style would be the only new additions to existing APIs. From there, the Block Editor would ensure that content editors can only ever select one style per category and that every style gets a live preview of the block.

Block Styles are the Future. Let’s Make them Awesome-r.

As Kjell Reigstad showed in his presentation at WordCamp US 2021, Block Styles provide an amazing way to give editors the power to build really creative designs. A single CSS class can trigger wildly complex and interesting visual changes to text formatting, image styling, and even animations.

The future of WordPress theming will require less and less custom CSS written by theme developers, but I think Block Styles will remain an exception to that rule. Block Styles make possible things that a content editor could never create with existing options.

In another talk at WCUS, Helen Hou-Sandí encouraged everyone in the WordPress community to keep pushing the limits of the block editor and imagine how it could be better for both editors and developers. That’s the true spirit of open source software, and I hope I’m living up to the call with this post and my involvement in feature requests like this one in the Gutenberg repository.

I think it’s worth improving the Block Styles feature, and I think this is how to do it.