Coming a bit late to the conversation around the new Section block (#13964). I don't like to resurface things that have already reached a consensus, however, I think the name for this block needs to change for a few reasons:
I'd propose calling this block Group instead, which seems more straightforward and less loaded as a term. (In the future, there'd be space for supporting specific HTML tags for the containing element, and converting a Group to a proper Section seems like a meaningful path.)
Finally, I'd strongly suggest incorporating a way to select multiple blocks and grouping them by using the block transformation tool — select a few blocks → open transformations → choose the "Group" block.
I believe it can be a more natural pattern for people to first create their content, then group it, rather than start with an empty container first.
Thanks for raising this. The arguments here make sense to me, especially if we add the "Group/Ungroup" actions.
I'm also good with "Group" as the name.
Finally, I'd strongly suggest incorporating a way to select multiple blocks and grouping them by using the block transformation tool
Would love to see a PR for this!
I agree with your logic here and wish I'd been as articulate in my responses when I was pushing back on "Section" in the original PR.
a way to select multiple blocks and grouping them by using the block transformation tool
Definitely a great feature and one which was requested during the work on the Block but felt to be out of scope. I would love to see this happen.
Also note if the name is updated we need to update the Github label (see below)
add the "Group/Ungroup" actions
Raises a question whether this would be a single block feature of Group or if we can build this on a framework level so all blocks with InnerBlocks
can be used for wrapping. Either opt-in (like supports: { wrapping: true }
) or maybe just the presence of InnerBlocks
could be enough signal.
Raises a question whether this would be a single block feature of Group or if we can build this on a framework level so all blocks with InnerBlocks can be used for wrapping. Either opt-in (like supports: { wrapping: true }) or maybe just the presence of InnerBlocks could be enough signal.
I was thinking about that as well. There were a few constraints I could think of. Firstly, I'm not sure if it is possible to determine that a block supports inner blocks from its blockType. Also, there are some blocks using a templated inner blocks with a locked template, or there's columns
which only accepts a column
as a child.
It seems like a supports
option might be the only way to go.
Alternatively a mapping function like transforms
use.
PR here 👉 #14920
The block is s no longer section
. Need support anchor ?
The block is s no longer section. Need support anchor ?
It should still support the anchor after the rename 👍
Also note if the name is updated we need to update the Github label (see below)
I updated the label name.
Most helpful comment
Thanks for raising this. The arguments here make sense to me, especially if we add the "Group/Ungroup" actions.