Patterns as Sectioning Elements

[mtias]

Since their inception, patterns were meant to be a very thin layer that just collected some blocks without any additional structure imposed on the block tree. This has many advantages for the way patterns are transported, inserted, shared, validated, and combined. However, when it comes to building templates and specialized pages, there has been a growing need for patterns to be more stable units at the root level of a document so that there can be an editing experience that focuses more on the larger placement of sections and less in its inner details.

Many ideas in the drawing board we want to work on — like a zoomed out view where you interact with sections only — depend on this structure being in place. The goal of this issue is to describe a possible path for combining many of the techniques developed so far that can allow patterns to be used as more controlled design elements, with more limited editing but very expressive capabilities.

This affects both insertion and editing. The step to get there is relatively minimal given all the tools we have already developed.

Block Type or Variation

There are mainly two ways to go about implementing these new sections:

• A dedicated block type with a “settings” and “styles” attributes (same format as block.json).
• A variation of the group block.

Each one of these approaches has pros and cons. The block type approach means that all the specific behavior is tied and colocated clearly in a defined block type. The downside is that the editor can’t support wrapper-less blocks easily, which means that we do need an extra div in both frontend and backend for each of these sections, and that container needs “layout” support as well.

The variation approach means that we don't need extra containers, we can just turn any part of existing templates/patterns to sections by setting a flag. We can reuse the current “styles” attribute and introduce a new “settings” attribute for these section variations. It'd also make it easier for other types of containers (Columns or third-party blocks) to also opt-in into some of these behaviours if we express them as supports.

A combination of the two can also be explored through the wp:pattern block that is available for themes.

Related: #27324.

Style Partials (theme.json)

There's a growing need for patterns to define visual aspects that can cascade to their child blocks. Right now this works either by establishing these attributes on a parent that supports them (like "color" in Group) or by repeating the style on every children. This is obviously inflexible for patterns that aim to have and retain more control.

The good thing is we already have a system to achieve this with theme.json, which was designed to provide styles and settings to control how blocks look and behave. It currently works at a global scale but making it work for sub-structures has been on the roadmap for a while (primarily targeted for specific templates, pages, and parts).

We can apply this technique of theme.json partials to these controlled patterns quite elegantly as well. Since the json config allows control over default styles, presets, elements, and settings, the expressive capabilities become a lot more interesting. This would allow patterns to exist as a harmonic unit, where child blocks are kept in check — for example, disabling specific design tools from them, or registering a restricted palette (imagine a "dark" element on an otherwise "light" site) that govern the look and feel of that section. We can think of it as a theme.json that is specific to a given section.

Another opportunity that opens up is the ability to offer style variations at a pattern level (the encapsulation of presets across all the available customization options) using the exact same mechanisms we have for global styles.

Related: #38167.

Locking and Absorb Toolbar

The ongoing work on locking mechanisms (#29864) is also a huge lift that when combined with UI settings like the "absorb toolbar" can provide a pattern editing experience that seems like a single entity even if composed of child blocks.

Generally, to achieve the best user experience when designing a page or template using pre-built patterns or “sections”, it is important to avoid surfacing all the inner blocks and low level building elements of that section. Users should be able to style and interact with these sections as a single unit and potentially dive into the smaller bits for advanced customizations.

If we combine the locking provided by the lock attribute, the inner blocks template, and what can be achieved with theme.json settings, we can achieve almost any degree of customization and control.

Right now, the editor optimizes by default for bottom-up customizations (clicking a paragraph in a section selects it first and the discoverability of the parent section become harder to reach. Given the children would be locked, we can also surface the movers of the parent even when a child is locked since we wouldn't have the issue of duplicated movers.

Cycling through Patterns

By having stricter structures that can be edited but not rearranged, transforming between different designs becomes more straightforward beyond what we achieved already for semantic template parts (headers and footers). This can allow a user to cycle quickly through variations of a section pattern while retaining its content customizations. While we have these features already in the ability to transform a pattern into another pattern, this can significantly simplify how these patterns are connected.

This is a feature we can surface in the container block toolbar, for example, in addition to the carousel explorations we added for template parts.

There's a question of how to conceptualize these variations (consider a pattern with an image, a heading, some text, and a button, arranged in different ways but with the same overall elements) when defining or registering patterns. We should look at it from the perspective of the patterns directory as well.

It's also important to discriminate between cycling between patterns that have the same elements and replacing a pattern / section with something else entirely. The latter we already support for template parts, for example. In the case of patterns, we should probably still retain the two, since you may cycle between variations of a "call to action" pattern or aim to replace that section with an entirely different "hero" pattern.

• Implement the concept of sections #40317
• Section specific Theme.json #40318
• Section overview UI (exploded view) #40319

[dmsnell]

These don't need to exist in the final render, right? Or do some kind of collected settings need to persist into the front-end, for example, for interactive view-time blocks?

If we have a need to pass through the organization to the rendered site, whatever that entails, then a group block seems not only a workable option but also a fairy central use-case for why the group block exists.

If, on the other hand, we mainly want to organize content inside the editor I wonder if we couldn't play a trick with the block system whereby we have a EditorGroup block that exists while editing, but is actually a normal block like the group block, just one that WordPress removes by default on render.

It would behave like the group block to collect a pattern's blocks, would be able to provide cascading data to its inner blocks, but the render filer on the server would strip it away leaving no div or any actual HTML tag in the output.

[simison]

[...] when it comes to building templates and specialized pages, there has been a growing need for patterns to be more stable units at the root level of a document so that there can be an editing experience that focuses more on the larger placement of sections and less in its inner details.

Have you considered surfacing different UI optimized for "sections manipulation" for anything that is at root level and has child blocks, without need for specialized container?

It could be confusing for layouts which have lots of small blocks at root level (e.g. paragraphs) but otherwise it could work well if it's contained to just site editor, and not be available to page/post editors.

[jameskoster]

I’ve been looking at ways we might establish a more pattern-centric experience for the creation (and editing) of templates. Many of the concepts discussed in this issue will be critical in achieving a better experience. Here's what I have so far...

Building with sections

A dedicated mode that optimises for browsing, inserting, and arranging root level block groups like Headers, Footers, and contextual Patterns can make template creation more ergonomic.

exploded.1.mp4

• Inserters prioritise patterns
• Abstracting complex block structure away might enable list view to be a more visual affair

exploded.2.mp4

• Each section serves as a drag-handle for easy re-ordering
• Different sections of a common type can be browsed via carousel
• Or replaced entirely via the pattern explorer
• Template Parts, Sections, and regular blocks get unique color treatments (Colorise template parts and reusable blocks in the UI #32163)
• Regular blocks can be deleted, but it probably doesn't make sense to surface patterns there

Flattened Patterns

Generally, to achieve the best user experience when designing a page or template using pre-built patterns or “sections”, it is important to avoid surfacing all the inner blocks and low level building elements of that section. Users should be able to style and interact with these sections as a single unit and potentially dive into the smaller bits for advanced customizations.

edit.mp4

In the video above you’ll see how toolbar absorption and block locking can dramatically simplify how complex groups of blocks are edited. This is similar to the current Buttons block, and the old Cover block.

We’ll need some additional exploration to figure out how the Inspector handles this., Eventually it can entertain all manner of affordances: style variations, localised color control, cascading styles for typography sizing, etc. This might be worth a dedicated issue.

Fine-tuning sections

Occasionally you may want to zoom in on a pattern for more granular control. The existing focus mode for template parts can serve this need quite well.

Entered via the more menu, you find all blocks within the section fully unlocked, and independently editable. This is where you go to add new blocks to the group, re-order, transform, and so on.

focus.mp4

---

Hopefully it goes without saying that the prototypes in these videos are still high level, there are many details still to work out, and I'm keen to gather feedback.

[nerrad]

Conceptually, template parts and sections appear to overlap quite a bit. What are the primary differences between them and why do they need to be distinct elements?

[jameskoster]

Reusable Blocks, too :)

My mental model defines Reusable Blocks as Sections that have been marked as globally synchronised. And Template Parts are Reusable Blocks that are marked with a specific purpose with regards to template composition. It's unclear how all this will ultimately manifest in the UX. There's plenty of interesting discussion around this subject in #34352.

[johnstonphilip]

Just looking for some clarification on terminology. The way I understand the term "pattern" today is that patterns are immutable. A pattern is not something the user can edit. Rather, they can clone a pattern when they insert it into the editor, and change their clone of that pattern, but it is not that same pattern.

One possible description of how I understand the term "pattern" today:
A pattern is a set of blocks that can be inserted into the block editor. Once inserted, it is no longer a "pattern", but a bunch of blocks that the user can edit as they need.

If I edit a "pattern", is it still that same pattern? I understand it to not be the same pattern.

If my understanding is correct, it would seem that what's being discussed here are not "patterns", but a "group" or "wrapper" concept, around a set of blocks. You've mentioned "section" as a term. That would work.

I'm just trying to understand why we are using the word "pattern" here at all.

[annezazu]

@johnstonphilip you might find this support doc helpful to address some of these terms, how things are used, etc: https://wordpress.org/support/article/comparing-patterns-template-parts-and-reusable-blocks/

[SaxonF]

Looking good @jameskoster!

To summarise challenges that I've observed two specific segments face:

Non-technical/no-code users want to minimize the time it takes to build their site but struggle to understand the block hierarchy, layout tools and just find design hard in general.

Enterprise users want to minimise reliance on developers, increase how quickly they publish content, and only publish content that is consistent with their brand.

Both of these segments would make use of increased focus on patterns combined with constraint tools like locking.

I assume that for both of these segments they mostly run into these challenges when composing pages, not templates. Templates would remain mostly in a default state provided by the theme. Related to some of our previous discussions around converging editors, I think whatever is designed for the site editor should also apply to the page/post editor.

Related to the above, will this mode essentially become the zoomed out view mentioned in other places?

Extending @nerrad comment, I really think we need to consider simplifying the mental model around block types. Introducing "sections" just complicates it even further. I will again reference @luisherranz comment here as I think its something that ideally should be figured out sooner rather than later.

The existing focus mode for template parts can serve this need quite well.

+1 to this. I'd argue against introducing different UI patterns unique to sections or the new mode. This also applies to the inserter, layers panel and swapping/replacing patterns and blocks. Instead of changing how the inserter and layers panel work when in this new mode, could we instead modify the existing panel? e.g. user can toggle between list and visual views in the layers panel. Likewise with the way swapping sections works, I wonder what it would feel like if it were consistent with the way blocks are replaced?

Generally, to achieve the best user experience when designing a page or template using pre-built patterns or “sections”, it is important to avoid surfacing all the inner blocks and low level building elements of that section. Users should be able to style and interact with these sections as a single unit and potentially dive into the smaller bits for advanced customizations

Another consideration is whether there are any improvements we can make to help people zoom in and out of the block tree.

There's a question of how to conceptualize these variations (consider a pattern with an image, a heading, some text, and a button, arranged in different ways but with the same overall elements) when defining or registering patterns. We should look at it from the perspective of the patterns directory as well.

Matching by comparing elements is a good starting point but I also really like what the Block Protocol are doing (click block schema) as a way to enforce content structure.

Have you thought about how this would all work on different layouts such as one that has side navigation?

Little details like spacing between sections to figure out but I really like where this is going!

[johnstonphilip]

@annezazu Yes that is helpful! It confirms my understanding of patterns. And really it means we aren't talking about patterns here at all. Perhaps this issue should be renamed from Patterns as Sectioning Elements to be Introduce Sectioning Elements for clarity?

[johnstonphilip]

Just thinking it probably would also be good to make sure we add "Sections" to that doc if/when this concept is merged in.

[jameskoster]

To @SaxonF's point above, I don't think the aim is to introduce a dedicated section 'element'. It's more about providing intuitive ways to handle root-level blocks, containers in particular. They can be groups, template parts, columns, you name it.

On that note, I share the sentiment that there's a lot we can do to simplify the myriad existing containers, along with concepts like patterns and reusable blocks. But I don't know that's something we should do as a part of this initiative.

[SaxonF]

That depends on the outcome of this conversation. I personally like @luisherranz suggestion here in combination with overrides as its consistent with existing design tools and creates more of a constraint driven editing experience which I know is something people desire. Anything that ends up in your library is "synced" by default or as Luis puts it Their changes are synchronized. If they are not synchronized, they just become blocks.

That being said, even if patterns aren't synced, there is still value in treating the pattern as a block itself (e.g. via parent first selection) and helping people navigate up and down its block tree. I just think there may be alternative ways to solve the challenges that toolbar absorption is trying to solve, but maybe I don't fully understand why toolbar absorption exists in the first place.

[jameskoster]

Do you think the 'parent-first' / 'flattened container' experience something we want to apply to all containers, or is it reserved for patterns?

If it is reserved for patterns, how do I dictate that one particular group is now a pattern, is it just a toggle in the inspector, or a flow similar to the creation of reusable blocks? Would it be confusing that some containers behave this way and others not... are we adding too much complexity?

If all containers exhibit this behaviour, how do I access full edit capabilities of the child blocks? Is that only possible in focus mode?

[SaxonF]

Do you think the 'parent-first' / 'flattened container' experience something we want to apply to all containers, or is it reserved for patterns?

Only patterns imo

If it is reserved for patterns, how do I dictate that one particular group is now a pattern, is it just a toggle in the inspector, or a flow similar to the creation of reusable blocks?

If block types end up being merged "create reusable block" would essentially become "create pattern" or "add to library".

Would it be confusing that some containers behave this way and others not... are we adding too much complexity?

I don't think so, particularly if other block types go away leaving just local blocks and synced (patterns). As long as we indicate which blocks are synced/patterns and which are local via colorising like in your concept or even with additional labels like the image below. The only difference in behaviour is that patterns are locked down except for potential attribute or block level overrides mentioned above as well as a more explicit global edit action to enter focus mode e.g. via double clicking or an "edit pattern" button

[jameskoster]

If block types end up being merged

This feels important, and makes me wonder whether we should prioritise things like #34352 and #40393?

[critterverse]

I wanted to share a couple variations of a Columns pattern that use the same inner blocks in case it's helpful for testing the swap functionality!

Pattern version 1
Pattern version 2
Pattern version 3

Here's the image used in all three patterns

[mtias]

The proposal of the wp:pattern block can help unblock some of the ideas here —— #48458

[annezazu]

Closing this out in favor of the following due to overlap #48458 Let's continue discussing there!