Gutenberg: Template Parts should allow setting HTML tag

[mtias]

Related: #20200

This is a setting that would make a lot of sense in the template part inspector controls settings. We should also see if template parts should be by default a variation on the group block, so that they inherit color controls, etc.

cc @youknowriad

[youknowriad]

Template parts right now don't render any markup right now, they should just use the Group block IMO. I'm tempted to consider this a duplicate of https://github.com/WordPress/gutenberg/issues/20200

and solved by https://github.com/WordPress/gutenberg/pull/20218

[mtias]

But we should make a decision on whether template parts should render markup by default using group. I'd say probably, yes.

[youknowriad]

I wonder if it can be a bit confusing UX wise:

• A user transforms some area of his template to a template part, a new div/section/whatever gets added automatically around that area.

Technically speaking, we have two options:

• Use InnerBlocks with a locked template containing a single group block inside template part. This leads to approximatively the same UX as today if you use a group block inside a template part, the oly difference is that this group block is enforced.

• Copy/Duplicate the Group block behavior in the Template part block. This might lead to a better UX (just one level of nesting) but there's a risk of code duplication and sync between the two blocks. That said, the group block is relatively small, so I might think that if we generalize the global styles support per block (color, line height...), it could be just a matter of adding a "support" flag in the end. If we go this route, I'd personally prefer to start with the generalization of the block global styles support first.

[mtias]

It feels like a template part is just an augmented "group" block. Particularly since we are also exposing the "convert this selection to a template part" which is equivalent to converting to a group. I think we should avoid extra levels of nesting as much as possible.

If we check what themes are initially doing, the group seems to come immediately after: https://github.com/WordPress/theme-experiments/blob/master/ambitious/block-template-parts/layout/header.html

[kjellr]

It feels like a template part is just an augmented "group" block. Particularly since we are also exposing the "convert this selection to a template part" which is equivalent to converting to a group. I think we should avoid extra levels of nesting as much as possible.

+1 to this. So far while building block-based themes, I have't encountered any use case where I _don't_ want the template part to behave akin to a full-width Group block.

[carolinan]

I have also used a wrapper for every section, but not always at full width.
In one example I used a group block around all templates, like a .site div, and I needed it to be narrower to create more of a boxed layout so I used the wide align.

[kjellr]

Makes sense — if there were a sidebar template part for instance, the full-alignment would not make sense. But I do think having some sort of container wrapper does seem like a common use case.

[MichaelArestad]

It feels like a template part is just an augmented "group" block. Particularly since we are also exposing the "convert this selection to a template part" which is equivalent to converting to a group. I think we should avoid extra levels of nesting as much as possible.

+1

It also just feels like I should get those same controls here to help "design" my site without adding the complexity of one more wrapper layer.

Reiterating (copy/paste) a comment from a related issue:

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.

Are there any reasons not to add markup?

[epiqueras]

Copy/Duplicate the Group block behavior in the Template part block. This might lead to a better UX (just one level of nesting) but there's a risk of code duplication and sync between the two blocks. That said, the group block is relatively small, so I might think that if we generalize the global styles support per block (color, line height...), it could be just a matter of adding a "support" flag in the end. If we go this route, I'd personally prefer to start with the generalization of the block global styles support first.

I think this is what we should do. Another layer of nesting here wouldn't be good.

[mtias]

We might want to allow an advanced setting on the template part inspector to be tag-less for the more rare occasions but still legitimate where you don't want a single container.