Implement the concept of sections

[jorgefilipecosta]

Part of #39281

Besides just marking that a block is a setting, the block should also contain some meta-information about what type of section it is, e.g., a 404, a call to action, etc. (I think this meta information can be stored as an attribute)

We have three options:

A new section block that patterns can use.
A group block variation, e.g., some attribute that marks that the group is a section and add/or add attributes with the meta-information.
A block supports flag. Any block can use a flag to specify using the supports mechanism it is a section. Using hooks as we do for colors etc, when we detect that the block supports being a section, we automatically add some attributes to the block, the UI reacts differently to show section information like name etc. Using this approach, groups, cover, columns, template parts can all be sections.
As part of the task, we should analyze the tradeoffs, choose one of the options and document why it was chosen, and then implement one of the options.

Without a deep analysis, I think the block support approach seems to be the right one (it allows any block to be section, even third-party ones), it does not involve any specific wrapper, and I don’t see any advantage to the other approaches provide.

The initial UI work of this task is small. I’m only expecting that if the section has a name/semantic meaning, the UI shows it on the block toolbar. Like on this mockup:

[colorful-tones]

Without a deep analysis, I think the block support approach seems to be the right one (it allows any block to be section, even third-party ones), it does not involve any specific wrapper, and I don’t see any advantage to the other approaches provide.

This does make the most sense. Avoiding additional wrapping <div> is ideal, and supports Matias's original observation: "The variation approach means that we don't need extra containers"

A new section block that patterns can use.

This option clearly has negative impact:

• Implies additional markup div wrapper
• Additional block in block library, which would confuse users: Section block vs Group block... what is the difference? Just agreeing on the name could become problematic.

A group block variation, e.g., some attribute that marks that the group is a section and add/or add attributes with the meta-information.

I can not imagine if there would be a UI necessary to surface this, or just something flagged programmatically? Again, it seems like a poor solution with complicating factors.

The initial UI work of this task is small. I’m only expecting that if the section has a name/semantic meaning, the UI shows it on the block toolbar.

I tested out the PR and it works as expected. However, I do feel like without the UI in List View to edit then this has potential to lead to user confusion (why does this block have a unique name?) and developer frustration, which could lead to abuse of the metadata attribute? 🤔

In the context of zooming out to the original larger picture within #39281 . With the potential for sections to be leveraged for providing context for variations. Would it worth considering how theme.json allows for core, theme and user customizations, and apply this to the metadata in your PR? So, if we allow users to change a section's name in List View, but we still want the possibility for a programmatic ID that can have variations then we might want to consider that the metadata object have those in the future? So, maybe metadata.name.user or metadata.name.theme? This is not entirely in the purview of this Issue.

This Issue and subsequent PR are a great step forward! 👍

[jorgefilipecosta]

It seems with blocks having names, patterns and zoom-out mode this issue is no longer relevant the innovation here is the metadata attribute that allowed multiple features and is complete.