Iterations on "Absorb Toolbar" mechanisms

[mtias]

One apparent difficulty that has risen with more and more blocks leveraging child blocks for controls (Buttons, Social Icons, Navigation, etc) is a general lack of intuitiveness when it comes to modifying attributes of the parent. Example: changing the alignment of Buttons when editing a single Button; changing the color of Navigation (a parent block attribute) when editing a single Navigation Item.

To address this, I'd like to explore ideas around when and how the toolbar and sidebar controls of a parent block could be exposed on their children. There are many challenges around clarity to overcome. This should not be a default true property, since groupings like Group, Columns, Cover, etc, should not present this behaviour.

[rickybanister]

I feel like there's a lot of opportunity to improve the parent selector. Something I find unintuitive about it now is that clicking on the selector then swaps the child toolbar for the parent toolbar in the original location.

I might find it more intuitive if the parent selector expanded to become the parent toolbar. I also realize it lives above the standard toolbar location which would introduce another problem, but perhaps an animation from the parent selector location to the standard toolbar location could help?

[mapk]

Looking at the Nav, Buttons, and Social Links blocks, which parent controls do we want to be accessible from the child block? Is this a boolean operation that either includes these controls in the child block, or should each control be marked individually to include?

Here's the block toolbars for each of those (parent on top, child block on bottom).

Navigation block
Parent block controls: Width, Alignment, and Block Navigator.

Buttons block
Parent block controls: Width and Alignment.

Social Links block
Parent block controls: Width and Size.

These designs still need plenty of iterations.

Ideas

Perhaps something as simple as showing those parent controls in the child block's toolbar. More iterations can be done around whether or not the parent controls should be visually different than the child block's controls to help differentiate them. But maybe this isn't necessary.

Another idea could be around animating the transition in the vein of @rickybanister's idea above. But I don't think this would work as well for accessibility.

[jasmussen]

In a related conversation, I shared some initial mockups for how the parent selector button could stay in context of the parent block, along with a boundary indication. It needs a little more thinking, but the heuristic seems like might work, as it's always just about the child and its immediate parent.

[mapk]

Thanks for sharing that, Joen. The 3rd option felt the best to me. I didn't care for the offset stacked toolbar when the top child elements was selected. Having them on the same line is stronger.

[rickybanister]

@jasmussen yes, the third idea is a wonderful expansion on what I was trying to communicate above.

[ZebulanStanphill]

Thanks for sharing that, Joen. The 3rd option felt the best to me. I didn't care for the offset stacked toolbar when the top child elements was selected. Having them on the same line is stronger.

The 3rd option did seem cool, but I don't see how it is even possible, from a technical perspective. How do you determine when to place the child toolbar to the side of the parent toolbar? The mockup has the very convenient case of the first child starting at the same point on the Y axis as the parent block. But what if the first child is further down due to a large amount of padding on the parent? This sounds like something that would take some complicated JS styling to pull off, which raises red flags to me.

[jasmussen]

This sounds like something that would take some complicated JS styling to pull off, which raises red flags to me.

The benefit of doing this in mockup form is that we aren't necessarily beholden to what's possible, but might simply spark new ideas or solutions we didn't think of (float: left; to the rescue?). I intentionally try to also explore things I know to be likely to not work, so as to not leave that stone unturned.

Worst case, we can get a visual feel for it, decide it's too onerous to implement, and we can point back to the conversation when someone in the future asks: "why didn't you try n". We'll have cauterized that idea, knowing it didn't work for us.

[gziolo]

I plan to work on further iterations for this mechanism.

Prior work can be found in #18440 PR. There is __experimentalCaptureToolbars experimental prop used with the Navigation block.

[gziolo]

I have a first working prototype #33955 for absorbing parent inspector controls. It works pretty nicely with the Buttons block. It sort of work with the Social Icons block, but I need to further investigate whether there wasn't any regression in that block.

[gziolo]

I haven’t made any progress since the last update so I unassigned myself in case someone wants to take it over.

[mtias]

There's nothing very concrete here, so closing for now. The content-only mode is a more thorough version of this anyways.