Size Change: +286 B (0%)

Total Size: 1.04 MB

_{compressed-size-action}

Nice! We should probably add the parent's tools as a toolbar group so it has a separation.

Very nice. This is before:

This is after:

Where should be parent controls located? It's the same group as in the parent in the prototype. Should we create a special group? Where should it be placed?

We should probably add the parent's tools as a toolbar group so it has a separation.

A few quick doodles. The Buttons block remains the same:

A "what if" that integrates the key parent toolbar options in the parent button selector. Doesn't feel right, but wanted to explore:

An entirely separate group. This one feels the best, but it does grow a bit wider:

The exploration might work better without the explicit drag handle as shown in the following. That isn't so much a suggestion for this PR as it is a reminder to keep thinking of how we can handle drag and drop in a more holistic way, perhaps make it a more dedicated part of the select tool:

Another thought: the Button toolbar gets pretty bordery in these mocks. Although the Link feature is technically block level and therefore separate, we migth consider curating it with the inline tools:

Should we create a special group? Where should it be placed?

I also think a separate group can greatly help usability as seen in @jasmussen's exploration. As a user, it would be very hard to understand why sometimes a block's toolbar has some options while others don't without knowing where those options are coming from.

Iteration 2: a new block controls group called parent located next to select a parent toolbar button

At the moment the parent toolbar group uses the standard class name block-editor-block-toolbar__slot but we can change it if we want to have better control over it.

By the way, it looks like the different distribution of children blocks is an expected feature in the Social Icons block when it's selected vs when it isn't.

Iteration 2: a new block controls group called parent located next to select a parent toolbar button

Nice one!

Can you visually separate the control groups with spacing, like the spacing we have between the parent button and the rest of the toolbar? Like in https://user-images.githubusercontent.com/1204802/128842093-85b815dd-a044-43dc-a77e-427eca34fc3d.png

As an update to the mockups in #33955 (comment) having discussed them in chat, the motivation was to clarify their parent relationship by sharing DNA with the parent button.

However that isn't necessarily any more clear in the mockups, the value of that DNA shared is perhaps also spurious, and it's less an "absorbing" of the toolbar than what is originally suggested. So perhaps we should just start with the simplest possible thing and learn from there:

Iteration 3:

It aligns with the most recent feedback:

So perhaps we should just start with the simplest possible thing and learn from there:

I also included changes that allow to opt-in to block toolbar capturing (__experimentalCaptureToolbars) for the parent block. When it is enabled, then two supported toolbar controls: align and duotone get exposed to child blocks. Example for the Buttons block:

There are two ways to test __experimentalCaptureToolbars:

• Navigation block uses manual __experimentalCaptureToolbars in the useInnerBlocksProps call so there are no controls exposed in the child blocks
• For the Button and Social Icons block it's easy to opt-out from toolbar capturing by changing the flag to false in block.json

It does get pretty long. Once we land this we'll want to revisit the feature where the toolbar bumps against the right side of the screen if inside a columns block. That used to work, but has been broken for a bit, ticketed it here: #34053

🌟 I really like this idea as I frequently find it frustrating that I have to select the parent to make certain changes.

Sorry to be "that guy" but looking at iteration 3 and then testing it, I am concerned that it's not obvious that the controls shown are associated with the parent.

It feels very much like they need additional visual affordance (over and above that provided by a separate group with a border) to "mark" them as distinct parent controls.

I worry it's going to be very surprising for a user if certain block-level controls suddenly start affecting other blocks (eg: parent) with no visual cue that they are distinct. If the user has to "learn" a UI pattern (eg: parent block controls appear to the left in a separate group) then that probably isn't going to cut the mustard.

For example, when I first tested this PR I intentionally didn't read too much of the description before hand in order that I could test the new feature without prejudicing my conclusions. My experience was that I was initially confused as to which control was the parent and I had to "hunt" for it until I realised it was the justification controls. There was no clear indicator to me - that will happen for others as well.

Just some ideas but have we explored...

• a "fly out" menu on the parent block selector icon that appears on mouseover?
• visually labelling the group of controls with text?
• color (I aware it's not ideal but as an additional affordance it might ok?)?

Really hope we can find a way to land this in a manner that doesn't add additional confusion to the toolbar.

Part of the thinking for absorbing toolbars is that there is no need to discriminate parent tools from child tools because the container ones are always available regardless of what is selected. Blocks that are entangled in this way will function more like a single block with contextual tools upon selecting an element within than separate child / parent blocks.

42e8030 tries a revised approach. When __experimentalExposeControlsToChildren is enabled in block.json then the following happens:

• the toolbar gets captured by the parent block
• align and duotone controls get exposed to the (direct) children blocks
• all toolbar groups explicitly marked as __experimentalExposeToChildren get exposed to the (direct) children blocks

At the moment when there is the following code:

<BlockControls group="block" __experimentalExposeToChildren>
     <SomeControls />
</BlockControls>

and the __experimentalExposeControlsToChildren isn't set in the block.json then controls don't get exposed. It's still something I'm not sure about. Anyway, we can change it later when we have more use cases covered. It would be great to look at the following blocks (among others) next:

• Navigation
• Cover
• Media & Text
• Columns
• Group

I rebased this branch with the latest changes in trunk. I plan to land the very first iteration tomorrow so we can include it in the Gutenberg 11.4 release to get more feedback from users and developers.

Sorry to be "that guy" but looking at iteration 3 and then testing it, I am concerned that it's not obvious that the controls shown are associated with the parent.

It's hard to tell if that is really a huge concern because the toolbar is rendered in the same place as the parent so maybe it's enough to have those controls in their own section. We can iterate on the design in the follow-up PRs and it's exactly how most of the features improved over time.

@annezazu I'm curious if we can do some testing with users on this one. Start from a pattern with three buttons on the page and ask: "change the second button text to blabla"; "change the alignment of buttons to be centered".

Definitely can. Do you want a full call for testing or are you okay if this is part of a larger call for testing in the future?