Pattern styles

[mtias]

Problem scope

When building a website it's common to have sections within the site that vary in style (colors, typography, etc). One section may be light and another dark. These sections may also use the same layout. To do this in the block editor you currently have to manually style inner elements and blocks for each and every section. This is not an efficient process.

If theme authors want to provide different variations of a pattern, they currently need to ship multiple patterns.

How might we simplify the styling process for end users and enable theme authors to ship multiple ways of styling content based on a single palette?

Strategy

This aligns with the goal of empowering designers and developers, as well as addressing needs of the enterprise sector. It balances the qualities of the end user experience and the needs of larger teams or maintainers creating constraints around styling.

Solution

Leverage the theme.json definition allowing it to be scoped as a block style. This allows the same mechanism used to style globally to apply on scoped elements. This can be blocks, patterns, or entire templates. Furthermore, allow subsets of style definitions to affect specific parts of the design by detecting when a variation only affects colors or only affects typography.

pattern-styles.mp4

Tasks

• Section specific Theme.json #40318
• Colors and typeset variations from theme style variations #56604
• Section Styling, Colorways, and Typesets for WP 6.6 #57537

[bgardner]

Following this issue closely, as this could be favorable for my Powder theme and significantly reduce the zip file since every pattern included comes in two flavors: Base and Contrast, and then Contrast and Base. (Which means 2x the number of patterns in the theme.) See below:

[MadtownLems]

I love that you're exploring this space! I made a similar post yesterday and it was suggested to comment here:

#59515

In addition to the concept of including the same pattern but with minor styling variations (alignment, color, etc) - it also floats the idea of taking user input while inserting a pattern ("Number of rows: ", or "Choose a column width: "), kind of like a "wizard".

[justintadlock]

Where I'm hitting the biggest snags with pattern styles is around Global Style Variations. I'll illustrate with a "Columned Post Header" pattern from my default variation (theme.json):

As you can see, it has a light gray background. By default, this uses a specific color preset from my theme. Because I have a pretty well-rounded color design system, this carries over pretty nicely to most style variations. For example, here's a dark variation that works really well:

Unfortunately, this isn't always perfect. That default background color sometimes needs to be changed per variation. Here's a different variation where the background is lighter than I'd like. This variation tends to use slightly darker backgrounds for things like this:

There are ways to define this background color for individual variations:

• Custom block style, but this is not always ideal if it doesn't need to be reused outside of this pattern.
• Custom theme.json property attached to a custom class, but there's no way to manage globally in the admin. The bigger concern of mine is that settings.custom properties are output on every page. The same is true if defined at settings.blocks.blockName.custom.

This is a simple example to illustrate this issue. There are times where I need to specifically design nested elements/blocks for each pattern and have those customizable across Global Style Variations. Custom block styles may be the answer in some scenarios, but (as of WP 6.5) you cannot customize those or their nested elements/blocks via JSON.

Here's a look at another variation where I'm changing the design of the post byline/metadata:

Note the different color of the byline/meta text and links and the customization of the Post Author Name block. I also don't want to change every instance of Post Author Name. That specific typography set is only needed when the block is used for in the byline/meta. I could register that as a separate block style, but I don't need that style across Global Style Variations. What I need is a method of saying, "Use these styles for this specific pattern within this specific Global Style Variation."

If I had just a few areas where this was needed, it'd be a less of an issue. But I find that I'm needing this more and more often to really take advantage of Global Style Variations and push them to their full potential.