^{Originally posted by justintadlock June 12, 2023}
Tutorial proposal:

One of the oft-repeated issues with WordPress' block styles system is that users can only add one style to a block at a time. More on this Gutenberg ticket: WordPress/gutenberg#14598

There are pros and cons to this system:

• Pro: It keeps highly distinctive styles from clashing.
• Con: You can't mix and match simpler or smaller design pieces that wouldn't clash.

There has to be a middle ground...

How to combine block styles?

That is the question that has frustrated many developers. For example, suppose you had a "Large Text" style and a separate "Gradient Outline" style for the block. Do you create a third style named "Large Text with Gradient Outline"? That is what some devs have resorted to, but it is a slippery slope with each new style you add. And, you would never do this in a solid design system.

At the end of the day, a block style is nothing more than a simple class that uses a standard .is-style-{$slug} naming scheme. The reason this is great for themes is that it doesn't negatively impact user content if/when users switch themes.

And this is (relatively) simple to recreate.

On the most low-effort DX end of the scale, you just have users input custom classes into the "Additional CSS Class(es)" box and call it a day. But, that makes for a poor UX.

On the other end of the spectrum, you build custom controls and let the user interact with them through the interface. Unlike custom blocks or plugins that add custom attributes, this system would use CSS classes under the hood. That means it also plays nicely with the WordPress theme review guidelines.

I've created several solutions in the past couple of weeks for testing this system. It works really, really well.

For example, here's a "Gradient Outline" picker that I put together:

Teaching theme authors block editor JavaScript

There are two things at play:

1. Theme authors must first learn how to set up the @wordpress/scripts package and integrate it into a theme. AFAIK, there is no documentation aimed directly at theme dev, but it definitely works.
2. Introduce theme authors to concepts that would typically fall under "block" development.

This is potentially a two-part series because both of the topics could be relatively beefy on their own.