This is an overview issue for expanding the block attribute sets and the user interface to interact with them.

Block attributes have evolved over time to fulfill multiple roles. Initially, attributes were a flat list, organized between toolbar and inspector controls in the block editor.

Over time, as more tools and capabilities were added, a few patterns have emerged that helped organize and distinguish between different types of attributes and their supporting interfaces—like the need to group "style" attribute together, facilitated by the evolving block supports schema. We also added "roles" to assist in transformations and other editor workflows.

I think it's time to put pencil to paper and formalize a series of aspects of block attributes and the overall block API further. We are in a much better position now in terms of project maturity and a large ecosystem of blocks to solidify the way these attributes should be organized. This can help bring a needed level of clarity and consistency to how blocks handle and present attributes.

Proposal

• Formalize the grouping of attributes in four groups: Content, List, Settings, Styles.
• Make the sidebar a full representation and editing interface of all the attributes a block supports (with the exception of utility and hidden attributes).
• Establish the block toolbar as a duplication of a subset of all the block attributes. Those that are considered "primary" attributes, which is up to each block's discretion outside of common supports.
• Connect attributes with types to produce interface controls (Data Forms) automatically. This is a longer effort that requires the design system and data form components to continue to evolve.

Notably, these attribute groups are agnostic about editing modes like "contentOnly". Which, by the way, is likely a misnomer, it should be treated as simpler editing or pattern editing, a subset of all attributes and block types. This means the block inspector should be able to render these four tabs as necessary depending on what a given block supports.

It also means that attributes that have only existed in the toolbar would be present in the inspector controls. Things like block alignment, text alignment (recently reintroduced in typography tools), media src, etc.

Let's dive into each group.

Content

This one emerged as part of the partially-synced patterns work and contentOnly mode. But it is a bit more expansive than that. For example, some blocks that deal with media have added a media item control in the sidebar as a setting, like the Site Logo has done. However, this has not been applied consistently across all blocks that contain media, nor to the image block itself. We should bridge this gap, since it's being propelled by the work on bindings, sync patterns, and simpler editing mode as a necessity.

The proposal is thus that all "content" attributes should be present in the sidebar and editable there, not just in the canvas or toolbar. For an image, that'd likely include "Src", "Caption", and "Alt". This would also clarify that "alt" text is content, and not a setting. This classification also helps know ahead of time what needs to be preserved on block transforms. The sidebar controls need to evolve to be fully powered by their corresponding field types.

List

This has been a single-use group added to assist with the complexities of the navigation block. It was done specifically on that block. The proposal here is to lift this up as a general block support that other blocks can opt into.

The reason for this is that there are a few blocks, in both core and in the ecosystem, whose structure (order and nesting) is a primary ingredient of the expected user interaction. For example, the List block, the Social Icons block, and the Buttons block can fall under that.

All these blocks struggle to have a representation in "content only" precisely because the order of the sibling blocks is important (and content only disables reordering). It's also contingent on allowing "blocks of the same type" to be inserted in a context, so a user can hit enter and add a list. A Social Icons block in content only is largely unusable because the order and types, which should be entirely up to the user, is prescribed.

All these blocks would benefit from a UI optimized for reordering and nesting, which is the list view. The List interface has also been built to allow drilling down into children to edit their content / styles. This should remain in place, with the caveat that a block that supports List, should be reflected as well in the Content tab as a link / pathway. This should be clarified with mockups because it can get a little complicated.

Settings

Not much to say on this one, it has been the original treatment of block settings and remains a distinct group. As we clarify the other groups, the remaining settings also get refinements through focus. The bulk of the work here is in developing the controls as part of declarative data forms.

Styles

Largely driven by block supports and the link with global styles. This has been mostly implemented thus far. In the context of "contentOnly" (simpler editing), styles should be more about presets and whatever the pattern has chosen to lift up in terms of customizability.

Roles

It is not clear that roles and attribute groups map one-to-one. We have discussed in the past having roles like "media" to help us systematize handling, but the emergence of types made that initial assessment a bit dubious: "media" could just be a specific "type" within a role="content" attribute. There's also a disconnect between a role declaration and the rendering of a component to handle the attribute. This would likely need to be approached from both sides (attributes type definition server side; grouping of declarative controls client side). The practical approach we took with style supports seems good to replicate here.

Bindings

Right now bindings are rendered as part of Settings under an Attributes panel. This is not the best, since it gets muddled in the sea of panels and uses a title that's not the most precise (everything in the sidebar is an attribute, technically). With the split between Content, Settings, and Styles, the bindings interface can be collocated with the specific attribute it modifies. If a user wants to connect the source content of a paragraph block, they'll find it in the "content" tab clearly marked and clearly connected. If they want to connect the caption of an image, they'll know where to access it in the sidebar as well.

Colocation of bindings would also mean we need to improve the clarity of a connected block at the top level. Right now the "purple" badge is only applied on the toolbar, but it should carry into the sidebar block type icon. Probably also allow it to be interactive there to show all bound attributes across the block (say in the future a style attribute and a content attribute are bound to a meta field or external data).

There's a few issues that need to be broken down and expanded from this one.