Gutenberg: Template part controls should be identical to a group block

[MichaelArestad]

Currently, the template part controls look like this:

I would expect them to be the same as the group block including the ability to go full width and change background colors. The full width aspect would be good in the near future for testing, but I expect will no longer be necessary if we add some sort of grid system to the template editor.

Here's what I would expect:

@epiqueras What do you think?

[epiqueras]

I'm not sure. I don't think sizing and alignment should be handled by it. Template parts should be thin block boundaries that fill their containers, just like reusable blocks.

We shouldn't mirror the group block and use all the same controls when you can just make a full-size group block the first child of the template part.

Colors and styles are a bit different because we will need global style controls for template parts in there. I guess we should limit controls there to what global styles offers, cc @ItsJonQ @mtias.

[mtias]

At the moment template parts don't render markup of their own, so they cannot have the same attributes as the group block. I've been going back and forth on this, because in many cases it'd make sense for a template part to define a semantic tag directly (header, section, footer, etc) without having to also add a group inside, which creates more nesting madness and not much clarity.

[MichaelArestad]

At the moment template parts don't render markup of their own, so they cannot have the same attributes as the group block. I've been going back and forth on this, because in many cases it'd make sense for a template part to define a semantic tag directly (header, section, footer, etc) without having to also add a group inside, which creates more nesting madness and not much clarity.

@mtias All good points.

Being able to semantically tag a template part feels very useful. Particularly as it could be a nice way to add a taxonomy to these template parts. This could make swapping out template parts fairly simple as headers could transform into other headers.

It feels to me these arguments strengthen the idea of iterating the template part block to have markup of their own to support various features and simplify the experience.

Are there any reasons not to?

[mapk]

I really like the points on semantics behind template parts. If we did allow the use of header, footer, section would we allow the template part creator the ability to assign that template part with the semantic options? I assume theme devs wouldn't have a problem here, but if someone was creating a template part from scratch, allowing them to select how they want the template part to be identified might be good.

[mtias]

There's more discussion on that here: https://github.com/WordPress/gutenberg/issues/20997

[noahtallen]

It sounds like the current feeling is to

1. Allow setting a tag (with possible opt-out mechanism)
2. Add group block controls to the template part block

Is that accurate? I would vote in favor of this approach because navigating around template parts is fairly tricky if a group block is outside or inside of the template part. Particularly in select mode, you have to click through multiple times, and it's tricky to select the actual wrapper in edit mode if there are multiple. It also sounds like wrapping a template part in a group block is a common use case (so far) by theme devs to add styling anyways, so first-party support seems good.

That said, from a technical standpoint, I want to note that we are talking about block attributes of the template part _block_. Specifically, these attributes would save to the containing parent not to the template part itself. So if you create a new template part block, make a new template part called header, set the template part block alignment to full, and set its semantic tag to header, those block attribute settings _only_ apply to the parent (since the parent is the thing storing the block itself). They would not apply to any other template part block which happens to reference the same template part.

Which raises some questions:

1. Should we only recommend putting a group block _inside_ the template part, so that it applies to all instances of the template part?
2. Should we accept that the settings only apply on a block level, not on a template part entity level?
3. Should we add some kind of way to persist these template part block attributes to the meta of the template part entity itself to solve the problem more comprehensively?

[MichaelArestad]

Is that accurate?

Yes.

Should we only recommend putting a group block inside the template part, so that it applies to all instances of the template part?

I'm not sure we should make either recommendation.

Should we accept that the settings only apply on a block level, not on a template part entity level?

No. While I understand the technical difficulties here, as a user, I would expect those settings to be part of the template part. If I insert the template part elsewhere, I expect, at the very least, it's background color to remain the same (group block settings). I don't know if the size settings should stay the same. I'm on the fence there.

Should we add some kind of way to persist these template part block attributes to the meta of the template part entity itself to solve the problem more comprehensively?

Yes.

[Addison-Stavlo]

Should we accept that the settings only apply on a block level, not on a template part entity level?

I have been thinking about this more and more lately. My initial reaction was "no", but there could be a strong argument for this approach. Im copying a comment I posted earlier today in another issue (https://github.com/WordPress/gutenberg/issues/22717#issuecomment-682729891):

---

Thinking about this more, there can be a solid argument for just using the block attributes for this kind of thing. No, it will not persist when you insert that template part on a new template, but maybe the template should have that control in the first place.

Consider the following example - A user wants to create a website to support bi-partisan political blogging. They want to use the same header across all pages of their site, but want different variations of the background color:

• Homepage / Info Pages / all-posts feed - They want the background of the header to be a linear gradient from blue to red.
• Pages that list liberal tagged posts - They want the header to be blue.
• Pages that list conservative tagged posts - They want the header to be red.
• Pages that list centerist tagged posts - They want the header to be purple.

If these settings are on the block attribute level, all these pages need is a different template that references the same template part. If these settings persist across the entity itself, not only would they need a different template for every situation, but a different Template Part as well!

Looking back at the semantic tag, this makes sense to be applied at the Template level as well. As the template is what determines where that template part is placed and what it is being used for in that specific circumstance. If a template supplies a template part block at the top of the template and lists its semantic tag as a header, its semantic tag should probably still be a header even if the user switches the entity it references to a template part that was initially intended to be a footer.

Now, we could ALSO use taxonomy to aid in the searching of template parts based on what they may have been intended for.. but in terms of applying specific wrapper styles and semantic tags it may make the most sense to do it at the block level as opposed to restricting the entity itself.

[noahtallen]

I'm on board with just leaving it as block attributes at the template level. The two things that persuaded me:

1. It's a lot easier to put a group block inside a template part and have it apply to all template parts than it is to put a group block outside of every template part.
2. None of the possible solutions to the problem seem to work in a clean way with nice API. On the one hand, we would be trying to directly block attributes into post meta of a different post, which would be pretty non-standard, and on the other hand, we would be trying to merge two template part block attributes with each other.

So I think just leaving it as normal could be the best solution here. From a theme dev standpoint:

1. You can apply attributes to template part block in the block-template HTML file.
2. You can make a style apply to every instance of the one template part by adding a group block to the root of the block-template-part HTML file.