Open mtias opened 2 years ago
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.
[...] 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.
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...
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.
https://user-images.githubusercontent.com/846565/161070179-ec59d7d2-0d6a-4545-a908-474c806bb200.mp4
https://user-images.githubusercontent.com/846565/161070225-0873c89f-16f3-4a8d-bd14-ce3261b5a161.mp4
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.
https://user-images.githubusercontent.com/846565/161070268-42ac5e99-e534-4076-888f-40c4707fda06.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.
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.
https://user-images.githubusercontent.com/846565/161076248-f661bd36-b3cc-461b-86b0-6c2ea3f1ea25.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.
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?
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 https://github.com/WordPress/gutenberg/issues/34352.
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.
@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/
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!
@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?
Just thinking it probably would also be good to make sure we add "Sections" to that doc if/when this concept is merged in.
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.
The way I use patterns to "cascade styles" right now is to add a custom CSS class to the blocks in the pattern or to the container block, if the pattern uses one. Controlling this with theme.json -or similar - would be an improvement.
For flexibility, I add template parts that only use one pattern block. That way the template parts which are repeated across the site can start out with the default content and can still be edited.
As a part of this work, it could be nice to allow renaming of containers. This can be useful in its own right, but in terms of working with patterns/sections it would enable us to use the pattern name for the inserted block(s), which would help with orientation.
This is exciting 🙂
Some thoughts:
Limiting sections to be only root-level would seriously undermine the number of issues they can solve:
Sections need to be fractal by design, with the ability to cascade effects by adding sections within sections.
To avoid cluttering the block tree with unnecessary wrappers, any block should be able to style/configure their children.
If any block could have this capability (instead of a single block type), we could move this configuration to the toolbars, and use an explicit name to avoid introducing another new name/concept.
The ability to style or control the children doesn't belong to the block intent. In other words, it should not be up to the developer in the same way that locking is not optional. Therefore, it should not be expressed as a block support.
I've explained my thoughts about the last points in more detail here.
@jameskoster I was thinking about this today and had a play with a couple ideas, hope you don't mind me throwing them in here.
Another way we could put more emphasis on patterns is to iterate on the block inserter so that both patterns and block categories would be visible rather than behind a tab. The most used core blocks (e.g. text, heading, layout, image) would remain accessible at the top as "favourites".
Also wanted to explain my earlier comment about keeping UI consistent regardless as to what mode you're in, as well as how this overlaps with "zoomed out mode". The video shown below is an example of how emphasising patterns might work in the post/page editor. The exploded view is really just a toggle to show/hide the surrounding template, so nothing special. When the surrounding template is shown, block categories could be minimized by default though I don't think that's necessary. It would also default to always selecting parent block/pattern unless the parent was already selected ie click twice to select children OR cmd click like Figma.
https://user-images.githubusercontent.com/1072756/168797203-1d2c76cc-7cb0-4b7e-8a5b-8b5812e59790.mp4
Heh, I've shared similar ideas regarding the Inserter as well, so agree there's scope to create a more holistic experience there, but perhaps it should be a focussed effort in of itself?
block categories could be minimized by default though I don't think that's necessary
Isn't this roughly the same as conditionally making the 'Patterns' tab the default? Not that I particularly love the tabs, just thinking about how we could implement these ideas incrementally.
The exploded view is really just a toggle to show/hide the surrounding template
Just to clarify – that's not quite the case. Rather, exploded view emphasises root level blocks and replacing (or adding) them by leveraging patterns (sections). Perhaps you're suggesting it should be the case? To that I would say: we have to be extra careful about blurring the lines between content editing and template editing to minimise the risk of users making far-reaching mistakes. In any case it's not clear how useful exploded view will be in the post editor – it may be best to implement it only in the site editor to begin with.
It would also default to always selecting parent block/pattern unless the parent was already selected ie click twice to select children OR cmd click like Figma.
This part goes beyond exploded view imo. There's a case to be made that this selection behaviour can be useful in all contexts. In the past we've discussed ways we might enhance select mode, and make that the default for certain views i.e. template editing. I go back and forth on this a lot, but would love to see some experimentation because despite trying a lot, I don't think we've got block selection quite right in the site editor just yet.
but perhaps it should be a focussed effort in of itself?
@jameskoster Perhaps, though I'd still say it contributes to the overall strategic theme of patterns. What's important when considering the exploded view solution though is whether we need an entirely new UI pattern. That just adds more complexity to our system.
Isn't this roughly the same as conditionally making the 'Patterns' tab the default? Not that I particularly love the tabs, just thinking about how we could implement these ideas incrementally.
It is yep and could definitely go the incremental route.
Perhaps you're suggesting it should be the case? To that I would say: we have to be extra careful about blurring the lines between content editing and template editing to minimise the risk of users making far-reaching mistakes. In any case it's not clear how useful exploded view will be in the post editor – it may be best to implement it only in the site editor to begin with.
Yep that's what I'm suggesting. Do we have any insights into where patterns are mostly used? I would hypothesise that they would be put to use in pages/posts just as much as in templates, at least for no code and enterprise use cases. Combine that with the known confusion between post/page editor and "site" editor plus the desire to see surrounding context when composing pages and I really think we should do what we can do stray away from designing solutions specifically for either editor.
This part goes beyond exploded view imo. There's a case to be made that this selection behaviour can be useful in all contexts.
Related to the above, exploded view is just one solution to the general strategic theme of pattern emphasis. What other ways are there to move that strategy forward? I'd love if issues like this were more problem/jtbd orientated and less solution orientated.
How might we reduce the complexity of our system and not add to it. It feels like this is a great opportunity to do that.
To be clear, I am 100% not opposed to viewing the template while editing a post :D I was merely cautioning the idea of patterns being a gateway to that as we need to provide perfect clarity when editing template elements. Perhaps there are other solutions to that problem though.
Still, just because you're editing a template, that doesn't mean you always need a pattern-centric experience. It may not be best to conflate these things. Overall I'd say that the need for pattern-centricity is fairly circumstantial, with some flows needing it more commonly than others. So doesn't it make sense for it to be built as an agnostic feature that can be invoked from anywhere, whether that is during template creation, or while editing a post, or even when zoomed in on a template part?
What other ways are there to move that strategy forward?
There is a key one detailed in this issue – the 'flattening' of patterns outside of exploded view. There is also the recently-implemented 'pick a pattern on page creation', and we intend to do something similar for templates. One nice thing about the exploded view is that it can theoretically supplant those last two by becoming the default view in certain editing flows (new template etc).
Another way we could put more emphasis on patterns is to iterate on the block inserter so that both patterns and block categories would be visible rather than behind a tab. The most used core blocks (e.g. text, heading, layout, image) would remain accessible at the top as "favourites".
This. It might even make sense to dilute the separation between blocks and patterns further, and instead combine patterns and blocks in the same categories:
A single image block, a single gallery block, a pattern combining an image and heading, or a pattern with 3 images in columns, might all be within the same "category" mentally when the user is seeking to insert an image on the page. Examples from Wix:
Similarly, a simple list block, and a more complex "list" pattern built from headings and paragraphs are both "lists" from user perspective so it makes sense to seek them under a single category:
So doesn't it make sense for it to be built as an agnostic feature that can be invoked from anywhere, whether that is during template creation, or while editing a post, or even when zoomed in on a template part?
It does make sense but I don't think we necessarily need a dedicated mode to do this. Figma, as a power tool, just defaults to selecting parent components/layers but also lets users double click or cmd click into child layers. What would a more casual approach to this be (but still catering to power users)? Could patterns/template parts/templates/re-usable blocks all behave the same way?
It does make sense but I don't think we necessarily need a dedicated mode to do this
You're right, a dedicated mode is only one option, and it may not be the best! I too am anxious about implementing a whole new feature, if incremental changes to existing features could solve the same problems. I think it's a worthwhile experiment though because it does a good job of creating a mental model for working with patterns/sections.
There are many dots to connect, and we need as many eyes on these problems as possible, so I appreciate the discourse 🙏
Could patterns/template parts/templates/re-usable blocks all behave the same way?
I think that's what the 'flattened patterns' element of this initiative lays the groundwork for. By obfuscating the block nesting through absorbed toolbars etc we make it easier to select and manipulate the section itself, and edit the contents within, without the need for any double-click patterns. We need to get the selection interactions just right for that, which is something that could probably do with some exploration. On that note, I like how in the latest figma update, hovering a group shows direct descendants with a dotted outline:
https://user-images.githubusercontent.com/846565/169038250-40fa0be9-4fb3-4334-8042-71c24c5aacfd.mp4
I spent some time today further exploring the ideas @SaxonF brought to the table and think the following incremental changes to existing functionality could be a valid alternative to exploded view.
To begin with, I agree that the concepts proposed in exploded view can be combined with the existing template editor to create 'layout view' which is accessed directly from the top toolbar.
https://user-images.githubusercontent.com/846565/169350838-b6570bc8-5af7-4404-b20c-8f3c7a1f9f80.mp4
Clicking the layout icon toggles the visibility of the full layout. This can close #27847. I'm not 100% sure whether the dark frame should appear when you're zoomed in on the post, or zoomed out to the layout (considering the concepts in #36667), but I don't think it matters too much either way. This exact same affordance can exist in the site editor, providing a way to fluidly move between template and content editing where possible. Perhaps we can finally bring the two editors into alignment? :)
In layout view the user has access to edit site-wide elements like the header and footer, so it is critical that we make every effort to indicate when such an element is selected. We can use the ideas in https://github.com/WordPress/gutenberg/issues/32163 to achieve this.
https://user-images.githubusercontent.com/846565/169351619-3c4a45ff-8452-420d-aa5f-6b4c3bbd6218.mp4
Local elements have the standard blue design accents. Global elements have orange accents, and in the case of headers and footers the icons in the toolbar echo the one in the top toolbar which will help illustrate their context. I'm unsure whether we need different colors for different types of global elements (reusable blocks, navigation menus, etc). The ability to save global elements inline will help here too.
Building on the idea of 'flattened sections', we can theoretically apply the following concepts to all containers, whether they are a 'section' as described in this issue, a template part, or even something simpler like the Cover block. The only thing that changes is the colorisation as outlined above.
https://user-images.githubusercontent.com/846565/169353525-64368e6e-e502-4bbf-8366-97014081795b.mp4
These behaviours combine to make any group of blocks feel like a single unit. The toolbar absorption element needs more work, because it doesn't always work so well. For example an Image inside a Cover:
We would also need to figure out exactly how nested sections work.
In order to make it easy to swap entire sections, we can provide access to the pattern explorer via the transform menu (we touched on this loosely in #40208):
https://user-images.githubusercontent.com/846565/169357054-ade5b10f-60ba-41e5-82e8-de3c4e6219e8.mp4
This would be accessible regardless of whether the section or one of its descendants is selected, like in the video above. This flow aligns better with other existing transformations when compared to exploded view, and has the added benefit of being permanently accessible regardless of whether you're in layout view or not.
Finally, we can do a better job of surfacing patterns in the Inserters. As I mentioned before, this feels like a bigger task that is worthy of a dedicated exploration.
It seems the zooming out needs to be much more prominent to communicate the arrangement of sections better and focus on inserter, dragging, and reordering.
@SaxonF thanks for sharing your thoughts!
I like a few things here that I think we can extract into separate issues:
A couple of other benefits of the dedicated "layout toggle":
author
s can intuitively view the full layout of their post without being able to edit the underlying template (due to block locking).It seems the zooming out needs to be much more prominent to communicate the arrangement of sections better and focus on inserter, dragging, and reordering.
Perhaps layout view can include a zoom affordance?
https://user-images.githubusercontent.com/846565/169797484-94d60ff8-e45c-43c9-a2da-6fd6fcf7b1e5.mp4
I like a few things here that I think we can extract into separate issues:
@mtias I can add a few more details to @jameskoster initial issue here if it makes sense. Grey material for inserter is slightly transparent and blurred to take on some colour from site behind. Lighter blue was just an experiment to see how canvas background would look if it were a lighter (or darker) variation of the dominant colour in current page. Technically challenging but simpler solution could be to use a light grey or darker grey depending on whether page is light or dark.
It seems the zooming out needs to be much more prominent to communicate the arrangement of sections better and focus on inserter, dragging, and reordering.
I like @jameskoster more generic approach to this as zooming could be useful in other scenarios. Zoom could even be a global setting accessible whether or not you have template/layout showing. There may be other ways to help with dragging e.g. When starting to drag a top level block/pattern, zoom canvas out but zoom back in when dropping.
edit: Just to add to the above, I'd love if we could get to a point where the components and tokens that make up WordPress itself are themeable allowing us to easily add light/dark mode which would also affect the canvas colour. If dark mode is enabled in Figma, default background is 1E1E1E
and light is FDFDFD
The toolbar absorption element needs more work, because it doesn't always work so well. For example an Image inside a Cover:
@jameskoster I wonder if we could draw inspiration from Figma's latest component property updates?
When creating pure blocks you can define attributes, where those attributes are sourced and how they are set (e.g. in inspector or toolbar). For patterns, rather than automatically absorbing properties in the toolbar I wonder if we could leave it up to the pattern author much like blocks?
The author would select which child block properties they want to allow to be overridden via the pattern. These properties could be appearance based like font size or colour, or whether to show/hide the block, or even the content itself. This could lead into some really interesting possibilities around synced blocks and overrides in future. It also may appeal to those who need more constraints in place.
This is a bad example but to show what I mean in this case author has decided the button font size is worth overriding.
The consumers of the pattern see these overridable properties when selecting the pattern.
That sounds very comprehensive. It would be good to specify defaults as well, for example the content of a Paragraph should default to editable where the size should not.
I struggle a bit to see a UI for handling toolbar properties. How would I disable the ability to change alignment on a Paragraph? 🤔 Perhaps a centralised view for toggling all block properties?
I struggle a bit to see a UI for handling toolbar properties
Are there any insights into what challenges absorbing toolbar properties on patterns would solve? I really like the idea of property absorption mainly when thinking about content based settings. e.g. clicking a hero pattern and being able to set heading, body and CTA without clicking through to child blocks would benefit low code users/editors. Do the people who struggle with navigating the block tree need to change low level properties like alignment?
If there is indeed a need for it we could look at some sort of hover interaction for each property
This is going a little crazy but could also look at bringing block style variations to patterns. This would bring patterns even more in line with blocks. In fact, a pattern would really just be a block that has been created in the editor and therefore can be exploded/detached into its individual blocks if needed. When creating a pattern in your library, you could create style variations of that pattern.
I suppose images are one example – you can only change the source via the toolbar. It sounds like you're suggesting moving that control to the inspector for patterns?
I suppose images are one example – you can only change the source via the toolbar
Images are a great example. Not sure how to solve that one. Patterns could contain multiple images which would complicate toolbar absorption further.
Revisiting an older idea, it would be a lot easier technically if you could make entire blocks overridable rather than attributes. This is kinda the opposite of block locking. Pattern instances would have blocks locked by default unless author decides it can be overwritten. It a block is marked as overridable it shows up in pattern inspector and toolbar for quick access.
One thing I'm still not 100% clear on is how we want to evolve patterns here.
Are we talking about them becoming global entities (essentially reusable blocks) that allow local overrides?
Or are we talking about simply 'flattening' the editing experience so they feel like single units, without any global synchronisation?
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.
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?
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
If block types end up being merged
This feels important, and makes me wonder whether we should prioritise things like https://github.com/WordPress/gutenberg/issues/34352 and https://github.com/WordPress/gutenberg/pull/40393?
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
The proposal of the wp:pattern
block can help unblock some of the ideas here —— #48458
Closing this out in favor of the following due to overlap https://github.com/WordPress/gutenberg/issues/48458 Let's continue discussing there!
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:
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 withtheme.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.