Clarify Group Block Layout Variants in Inserter and Placeholder UI

[tomdevisser]

What problem does this address?

When adding a Group block, the editor prompts the user to select a layout (e.g., Row, Stack, or Grid). However, selecting one of these options causes the inserted block to appear as a different block entirely — even though it’s technically still a Group block with a layout variation.

This leads to confusion, particularly in the List View, where users don’t see “Group” and instead see “Row” or “Grid,” which feels like they’ve added a completely different block. The disconnect between the technical reality (all are Group variants) and the UI presentation creates a cognitive mismatch that makes the editor feel unpredictable.

What is your proposed solution?

Either:

• Remove the placeholder state when inserting a Group block to eliminate ambiguity about what is being added; or,
• Update the placeholder text to clarify that the user is choosing a layout variation of the Group block.

Example: Change the message from “Group blocks together. Select a layout:” to “A container for your blocks. Choose a default Group, or one of the other layout blocks.”

Additionally, consider labeling blocks more transparently in the inserter (e.g., “Row (Group)”) to reflect their shared origin and reduce the perceived complexity.

Related discussion: View full Slack thread for context and additional details.

[tomdevisser]

CC: @fabiankaegy @karmatosed

[t-hamano]

Thanks for the report.

I think this problem is the same as #66062.

The current implementation of the placeholder in the Group block is intentional. See #67083 (comment). To hide the visual text, a custom implementation is used instead of the BlockVariationPicker component.

Remove the placeholder state when inserting a Group block to eliminate ambiguity about what is being added

There is an #67083 that takes this approach, but it doesn't seem to have reached a conclusion yet.

[tomdevisser]

@t-hamano Thanks! There are similarities with those tickets, but I think the focus is slightly different here.

The other issues are mostly about the UI of choosing a variation — how that selection is presented and handled visually. This ticket is more about clarifying what you’re actually adding: are you picking a variation of the same block, or are you switching to a different block entirely?

For example, when you choose a variation of the Query Loop, the block still shows up as “Query Loop” in the List View — which makes it clear you’re still working with that same block. With Group variations, it’s the opposite: the UI makes it seem like you’re switching to a different block type (e.g. Row or Stack), but you’re actually just selecting a variation of the Group block. That’s the confusion this ticket is trying to address.

[t-hamano]

the UI makes it seem like you’re switching to a different block type (e.g. Row or Stack), but you’re actually just selecting a variation of the Group block. That’s the confusion this ticket is trying to address.

I see, that's interesting.

It's probably not difficult to display the block name along with the variation name. Here is a example diff for adding block names in the List View:

Details

diff --git a/packages/block-editor/src/components/block-title/use-block-display-title.js b/packages/block-editor/src/components/block-title/use-block-display-title.js
index a51b336554..c07e8e7662 100644
--- a/packages/block-editor/src/components/block-title/use-block-display-title.js
+++ b/packages/block-editor/src/components/block-title/use-block-display-title.js
@@ -1,6 +1,7 @@
 /**
  * WordPress dependencies
  */
+import { __, sprintf } from '@wordpress/i18n';
 import { useSelect } from '@wordpress/data';
 import {
        __experimentalGetBlockLabel as getBlockLabel,
@@ -59,7 +60,14 @@ export default function useBlockDisplayTitle( {
 
                        const match = getActiveBlockVariation( blockName, attributes );
                        // Label will fallback to the title if no label is defined for the current label context.
-                       return match?.title || blockType.title;
+                       return match?.title
+                               ? sprintf(
+                                               /* translators: %s: Block variation title. */
+                                               __( '%1$s (%2$s)' ),
+                                               match.title,
+                                               blockType.title
+                                 )
+                               : blockType.title;
                },
                [ clientId, context ]
        );

However, it's important to note that displaying block names in blocks other than the Group block can feel a bit redundant:

[fabiankaegy]

My personal take here is that the placeholder state of the group block should be removed altogether. It creates more friction and confusion than it is helping...

If we are not willing to do that I think the second best option is to change the instruction text inside the placeholder to be more clear so that users aren't confused why they added a group and ended up with a block named grid...

I personally don't really like the idea of showing the name of the block next to the variation name. It just adds a lot of visual clutter...

[hanneslsm]

I think overall we're running into the issue what to display and how (in the list view but also in the toolbar and inspector)

1. Block
2. Block Variations
3. Block Attributes (e.g. H2, H3, H4…) Related: List View: consider showing heading level and ensure aria label shows heading level #54631 and Show Heading level in the sidebar #42181
4. Other attributes like locked, sticky group and HTML Anchor
5. Colors for template parts & synced patterns
   …

I agree with @fabiankaegy that we shouldn't just add the name to the list view but we need a overall concept on how to display blocks, block variations and attributes.

[tomdevisser]

I agree with @fabiankaegy that we shouldn't just add the name to the list view but we need a overall concept on how to display blocks, block variations and attributes.

Maybe one idea could be to add the Group icon next to the labels like “Row,” “Stack,” and “Grid”?

[t-hamano]

I want to understand what kind of problems block variations cause in the first place. Why do we need to show the name of the block that the variation originates from?

Personally, I don't want users to have to be aware of whether it's a block or a variation. I don't think non-developers who create content even know the concept of variation.

By the way, you can find out why the placeholder was added to the Group block in #43433.