Semantic Template Parts

[mtias]

Once a subset of template parts start to be defined (#26599), it'll open up the doors for some work we have hinted at before.

• Template-Specific Patterns. Once we identify a template part as being a header area, we can offer a subset of available patterns of a category header. The creation flow of a template part that is marked as a header can be optimized for that specific flow, allowing users to choose from different global headers. Themes could also supply a few variations of their header, ensuring they only show up for the header template part and not as regular patterns.
• Block Filtering. Since we know a header area is likely to include a site title, site tagline, logo, navigation, etc, we can surface those blocks in quick inserters by default.
• HTML Semantics and Accessibility. We could suggest or enforce certain HTML like <header>. We could also warn if a header doesn't contain a site title, or if the site title is not set to using h1. Knowing template regions is also highly valuable for naturally including elements like FSE: Add skip link #21507 (root or header).
• Theme Switching. Knowing that a template part is a header is a very valuable asset on theme switching, since we can do a lot more in trying to map certain content from one theme to another, or allowing a user to swap the header from a theme with another one.

Any other ideas where we can leverage the added knowledge of semantic template parts in the editor?

[jameskoster]

Couple of other UX options:

• Optimise the template part switching UI. If you're switching a header template part, it probably makes sense for the UI to present other headers before all template parts as it does now.
• If/when we create a mosaic view for template parts we can offer semantic filters / categorisation therein.
• Streamline from-scratch template creation by automatically inserting a header and footer template part.
• Quick inserter shortcuts? Type /header and see header template part variations.

[ianstewart]

Potentially useful for providing consistent semantic class names for styling.

[mtias]

It seems we'd need to work through something like a term set that we can maintain and augment, starting with header and footer. These should probably be exposed in the inspector for a template part so the user can specify if a template part they created is a header, etc.

[Addison-Stavlo]

Template-Specific Patterns. Once we identify a template part as being a header area, we can offer a subset of available patterns of a category header.

It seems we'd need to work through something like a term set that we can maintain and augment

The term set makes sense to me. Should a theme be able to supply more than 1 of these terms for a template part? If not, we can use the tagName block attribute as the first item to start the term set. If so, I suppose we need to add a termSet or categories type of block attribute so a list could also be supplied through markup?

I wonder if we should also:

• restrict changing the tagName to only items present in the term set.
• restrict both tagName and items of the set to be valid semantic HTML elements.

Also, when inserting a template part that has multiple items in the term set - how should we go about deciding which to use as the default tagName? With only one item it would be clear, but with multiple options do we 'force' the user to make that selection at the time of inserting the template part? 🤔

[jameskoster]

Should a theme be able to supply more than 1 of these terms for a template part?

Are you asking whether a theme should be able to specify that a template part is both a Header and a Footer? I hadn't considered that yet but can definitely see a use case. It would be convenient to not have to duplicate a template part if you want the site header and footer to be identical.

The usefulness evaporates somewhat when you think about the other categories though... I'm struggling to think of a situation where a template part for displaying content could also be used as a header, or a sidebar... it'd be good to get some input from themers here I think cc @kjellr.

do we 'force' the user to make that selection at the time of inserting the template part?

I think so, yes. Considering some of the other work we have planned around template parts, it seems unlikely that users will ever insert a "Template Part" block. Instead they'd insert their "Header with large logo" or "Header with small logo" block. These are template parts under the hood, but more intuitively named and accessed.

[Addison-Stavlo]

Are you asking whether a theme should be able to specify that a template part is both a Header and a Footer?

Yeah. More specifically my comments above are trying to make sure I understand @mtias comment about the "term set that we can maintain and augment". To me 'term set' means it can contain multiple items. So does that mean a specific template part contains a 'term set' and can be associated in multiple ways as you note above, or does that mean we have a 'term set' of available types and any given template part may only be associated with one of those terms at a time?

[jameskoster]

I anticipate the latter, at least to begin with. The former feels to me like something we could consider adding after we've explored the use cases further and got more input from themers.

[kjellr]

The usefulness evaporates somewhat when you think about the other categories though... I'm struggling to think of a situation where a template part for displaying content could also be used as a header, or a sidebar... it'd be good to get some input from themers here I think cc @kjellr.

Since template parts can really be anything, I think there's value to allowing flexibility here. Maybe you have an aside sidebar that is also used in a footer on certain pages. You could have a section template part on the homepage that also exists as its own full page template, etc.

[mtias]

To clarify the intention here: my expectation is that there will only ever be one header, one footer, and so forth when it comes to template parts. With "term set" I just mean the list of viable terms we'd support like for post formats, not that you could have more than one applied.

It's somewhat equivalent to header.php and footer.php (though doesn't respect linearity) in that they represent logical places where we can make certain assumptions like hook in a "skip to content" link. It wouldn't make sense to render the header twice in the footer because the user would end up with a duplicated h1, etc.

Patterns can always be categorized as pertaining to both headers and footers if the design makes sense.

Template parts are already very flexible and loose, so I'd suggest starting very simple with these (only header and footer to start with).

[carolinan]

Wouldn't template part specific block patterns be extra steps and more complicated?
This is why I don't think we can assume that a theme will only have one header template part (unless we force this?):

Compare the following:

The theme offers 3 header designs in 3 different header template parts.
The user selects the header template part. Clicks the arrow icon in the toolbar, sees the name and preview of header-3. Selects Header 3. Updates design.

and:

The theme offers 3 header designs in 3 different block patterns and one header template part.
The template part already has the default header design.
The user selects the template part and deletes all existing content.
Opens the block inserter and selects the header category.
Previews the block pattern, drags it in place. Updates design.

The theme author would choose between providing extra HTML files or registering block patterns and block pattern categories.
The default template part is assigned to the header area in theme.json.

[jameskoster]

If there is only a single Header template part, how would I configure a unique header design for pages on my site?

Granted I could open the Page template, delete the Header and insert a pattern at the root level. But doesn't that kind of undermine the point of template parts?

There is a lot of conceptual overlap between patterns and template parts, but I am not sure we can escape template part variations. Especially if we want to support things like content-{$slug}.

[aristath]

I believe there is just some terminology confusion...
There should be a single header termplate-area where users will be able to assign one of the template-parts that have been marked as header.

[mtias]

@jameskoster another thing to take into account is how we surface these in the W menu for the current template.

[jameskoster]

IMO the W menu is a more agnostic navigation tool and probably shouldn't highlight anything template-specific – it should always behave the same regardless of which template is being edited.

That said, there are several other locations we can surface parts relevant to the current template:

• Template dropdown in top bar
• "Template" tab in the Inspector
• Preview/View menu

[mtias]

Yes, thinking more about it I think we need to make better use of the template dropdown and template inspector instead.

[Addison-Stavlo]

Now that template parts have their area terms and corresponding variations applied (giving context for patterns, semantic html elements, searching other like entities, etc.), I am wondering if we should close this issue? Or leave it open for further discussion on more ways to leverage these classifications?

[mtias]

Theme switching is one area that is still not fully explored, but we can do that separately.