The word Section Styles immediately makes me think of the <section> HTML element.
Indeed the term relates to sections of a page, meaning a distinct, self-contained part of a webpage.
So far WordPress didn’t have a way to style these sections. But WordPress 6.6 changes this with the Sections Styles feature.
And not only will this feature reduce the need for repetitive manual configuration of styles. It also will lower the number of required patterns, reduce the need for CSS, and ease website maintenance.
In this article, we’ll dive into:
- Why use section styles?
- About Atoms and Molecules
- The downsides of Patterns
- The downsides of partially synced patterns
- How Section Styles solve these issues
- Implementing a Section Style
- Limits of Section Styles
- Implementing section styles in your projects
Why use section styles?
WordPress block themes use Global Settings and Styles instead of CSS. This styling system allows developers to create styles that apply to:
- The entire page
- Select HTML elements (headings, button, caption)
- Block types
- HTML elements within block types
- Variations of block types
So, while this offers enough fine-grained control for efficient styling, it has one major downside.
And that is that there is no good way to address parts of a page. Indeed the most fine grained level that you can go is the block level.
Before WordPress 6.6 there was no way to create styles for collections of blocks using Global Styles.
About Atoms and Molecules
When thinking about design systems, I like to use the model established by Brad Frost in Atomic Design:
In WordPress language, the atoms are the blocks:
And molecules are the patterns:
And this is something that we are familiar with from classic themes. You have your basic elements, and apply default styles to them. And then when you arrange these elements into a particular way, add styles specific to that grouping.
And we could replicate this in block themes…. kind of.
You see as professional developers, we want to keep styles in theme.json . Because using the Global Styles system is the only way to benefit from the same ease of maintenance as we are used to from CSS.
But what if we don’t have a way to style blocks through this system? So far the answer has been: use a pattern.
The downsides of Patterns
So what you would do is take the blocks with their default appearance, and package them up into a pattern. And any deviation from the default styles was applied to the blocks in the pattern through the styles interface.
But patterns have several issues:
- The styles added directly to blocks is stored along with the block in the post or template content. Which makes it impossible to change the styles afterwards without manual intervention.
- Since content and styles are all mixed together, you cannot keep the content, and switch out the styling without manual changes.
And synced patterns did not help solve this challenge either, since they keep both the content and the styles in sync.
WordPress 6.6 will introduce partially synced patterns. This pattern type solves the issue of keeping design in sync, while making the content editable.
So does this solve the problem?
The downsides of partially synced patterns
Let’s start with the most important downside. And that is that partially synced patterns, much like synced patterns, are stored in the database. Indeed both are instances of the wp_block post type. Or in other words: partially synced patterns are content, and not templating.
This creates an issue for freelancers and agencies, as our theme development workflow relies on using source control. You can of course use Git or other source control tools with block themes. But only for elements that are part of the theme, and not for content.
The second issue is that while you can override the content of the blocks that have overrides, all the rest of the changes done to the pattern do sync.
Let’s take this pattern for example:
So what if I want to add a second button? I can do that, and the block will show everywhere where this pattern is used.
While this is useful, it also means that you need to have a separate synced pattern for each of the content variations. Because one could have this exact same structure and styling, but maybe without the “Launch faster” pre-heading. Or with one, two or even three buttons.
So one can see how this can quickly get out of hand, and the number of patterns would grow to large to be easily manageable.
How Section Styles solve these issues
Section styles solve all of the issues outlined above:
- You can apply them to specific block instances, targeting individual blocks on individual pages.
- You can create the styles using theme.json, and track them in source control.
- You can change the inner blocks freely.
We’ve seen that Global Styles apply to the entire page. Section styles apply to parts of a page.
So how is this part determined? By the block that the style is tied to. Unlike block styles though, section styles can apply to several blocks all at once.
Implementing a Section Style
The Ollie theme contains three patterns with the exact same structure, but different colors:
Wouldn’t it be cool if this were the same pattern, but with different section styles? Let’s see how far we can get on that.
We’ll start with the last pattern, and create a section style for that. Once we have done that, all we need to do is duplicate that style, and change the color values to match the two other patterns.
Step 1: Registering the section style
The most straightforward way to register a section style is to rely on WordPress’ autoregistration.
So create a JSON file, and put it into the styles directory in your theme. While WordPress doesn’t impose any naming, I like to use section-style-<name>.json.
Inside of the file, put the following snippet:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"title": "Accent",
"slug": "accent",
"blockTypes": [ "core/group" ]
}
Code language: JSON / JSON with Comments (json)The lines to customize are:
- Title: This is the name of the style that is visible to the user. You can choose this freely.
- Slug: This is the internal identifier of the style. This needs to be unique, as it is used as a CSS class.
- Block Types: The block types to register the style for. You can choose one or several block types.
Step 2: Implement the outer block styles
With this prepared, we can implement the styling. We’re going to start with styling the block to which the section style is tied. In our case this is the group block.
We need set the:
- Background color
- Text color
- Border radius
- Padding
This is how this looks in theme.json:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"title": "Accent",
"slug": "accent",
"blockTypes": [ "core/group" ],
"styles": {
"border": {
"radius": "5px"
},
"color": {
"background": "var:preset|color|primary",
"text": "var:preset|color|primary-accent"
},
"spacing": {
"padding": {
"top": "var:preset|spacing|large",
"right": "var:preset|spacing|large",
"bottom": "var:preset|spacing|large",
"left": "var:preset|spacing|large"
}
}
}
Code language: JSON / JSON with Comments (json)As you can see we use var:preset|color|primary to reference colors from the color palette. This way we tie our custom styles into the wider design system for maximum consistency, efficiency, and flexibility.
Step 3: Implement the inner block element style
With the outer block done, we’re going to move on to the inner blocks. Or in other words: the block inside the group.
At this point, we got everything covered except the link:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"title": "Accent",
"slug": "accent",
"blockTypes": [ "core/group" ],
"styles": {
"border": {
"radius": "5px"
},
"color": {
"background": "var:preset|color|primary",
"text": "var:preset|color|primary-accent"
},
"spacing": {
"padding": {
"top": "var:preset|spacing|large",
"right": "var:preset|spacing|large",
"bottom": "var:preset|spacing|large",
"left": "var:preset|spacing|large"
}
},
"elements": {
"link": {
"color": {
"text": "var:preset|color|primary-accent"
}
}
}
}
}
Code language: JSON / JSON with Comments (json)Step 4: Implement the styles for inner the blocks
This leaves one last piece to style, and that is the separator. For this we’ll target its block type selector:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"title": "Accent",
"slug": "accent",
"blockTypes": [ "core/group" ],
"styles": {
"border": {
"radius": "5px"
},
"color": {
"background": "var:preset|color|primary",
"text": "var:preset|color|primary-accent"
},
"spacing": {
"padding": {
"top": "var:preset|spacing|large",
"right": "var:preset|spacing|large",
"bottom": "var:preset|spacing|large",
"left": "var:preset|spacing|large"
}
},
"blocks": {
"core/separator": {
"color": {
"text": "var:preset|color|primary-accent"
}
}
},
"elements": {
"link": {
"color": {
"text": "var:preset|color|primary-accent"
}
}
}
}
}
Code language: JSON / JSON with Comments (json)Step 5: Testing the section style
We can now go ahead and remove all the per block type styles of the pattern, with the exception of that applied to the “Post Page” text.
The pattern at the top is the original with all the styles set on the blocks. The one at the bottom uses the section style:
The so while the appearance doesn’t change, the second pattern has a lot less markup. This is because we moved the styling out of the pattern, and into theme.json.
Step 6: Create the other two section styles
Now all we need to do is duplicate our section-style-accent.json file, and then change the color values.
This is because once you have the right setup, it’s just a matter of filling in the blanks.
Limits of Section Styles
As powerful as section styles are, they do have their limits.
The first is that you while you can target elements and blocks, you cannot distinguish between several occurrences of this.
What does this mean? In the pattern we see the “Post Page” text. It is a paragraph, as is the text below. So in order to get it to have a different color, we need to set it on this specific block.
Of course one could use a Heading block instead. This would allow us to target it through the Section Style. But from a structural standpoint, this wouldn’t be appropriate.
So while Section Styles can replace patterns for a lot of cases, it doesn’t replace them in all scenarios.
The second limit that Section Styles have is that is they work well with blocks that are made up of several elements. Most blocks in WordPress only represent when element: a Group, heading, paragraph,…
But some blocks like the Navigation block contain several elements. And in case of the Navigation block, the styles for this elements can only be added through the interface.
These styles are stored as settings on the block:
<!-- wp:navigation {"ref":98,"textColor":"base","overlayBackgroundColor":"main","overlayTextColor":"base","style":{"spacing":{"blockGap":"20px"}},"layout":{"type":"flex","orientation":"horizontal"}} /-->
So as these are settings, and not styles, it’s not impossible to control them through Global Styles.
Implementing section styles in your projects
Even with these downsides, section styles are highly useful.
So should you now go ahead and refactor all your patterns? Not necessarily. You need to weigh the upsides and downside.
While creating section styles is fast, it still takes time. So don’t change your client’s themes just for the sake of refactoring.
However if you need to implement a new design, or change an existing one, then this is the time to go ahead and use this new feature.
And as section styles can span across different block types, you should be to consolidate the styling into a few key section styles.
But for new project, there’s no doubt: use section styles, and only rely on patterns if needed.
