Incorrect border radius when only one color panel item

[richtabor]

The border radius is incorrect if there is only one color panel item. It should be $radius-block-ui on all corners.

We currently add .first and .last classes to the .block-editor-tools-panel-color-gradient-settings__item, but they don't account for when there is only one item.

You can see this example within the Featured Image block.

Current	Expected

[aaronrobertshaw]

We currently add .first and .last classes to the .block-editor-tools-panel-color-gradient-settings__item, but they don't account for when there is only one item.

To clarify, the .first and .last classes are added to the ToolsPanelItems rendered into the ToolsPanel rather than the .block-editor-tools-panel-color-gradient-settings__item elements.

The catch here is that the color panel actually has two tools panel items. The second one is the overlay slider that was injected into the color panel in #43838. It receives the .last class.

I'll see what I can do to get the correct border radii on the color items.

[aaronrobertshaw]

One option in terms of a fix is available in #55071 however it relies on a generated class name by the ToolsPanel components so might not be acceptable.

[ciampo]

Hey folks, I took a look and I'll leave a few thoughts:

• Is there a reason why we're not using Item and ItemGroup ? Those components should already automatically embed functionality for displaying border and having rounded corners only on the first/last item (example)
• Alternatively, if we want to continue to rely on a Button + custom styles, what if we changed the logic of the CSS to be able to target first and last instances of those buttons without relying on .first and .last classnames — I quickly put together an example of how we could about it here . The only caveat is that it relies on :has, which is not supported by Firefox yet (although it should be in the upcoming weeks, although I don't see that as a blocker.

[aaronrobertshaw]

Thanks for weighing in @ciampo 👍

Is there a reason why we're not using Item and ItemGroup

This was explored when the color panel was converted to the tools panel.

Off the top of my head, there were a couple of issues with this including the fact that non-Item controls could be rendered into the panel's slot and that to ensure consistent order of controls those that aren't currently being displayed still require a placeholder element to hold the position in the DOM.

[aaronrobertshaw]

#34027 provides some context as to why Item and ItemGroup couldn't be used.

Alternatively, if we want to continue to rely on a Button + custom styles, what if we changed the logic of the CSS to be able to target first and last instances of those buttons without relying on .first and .last classnames

I don't think this covers the situation where hidden placeholder elements are in the DOM to maintain order of controls given slots don't guarantee the order of their fills. In the example sandbox linked if you add display: none to the last item you'll see the border radii disappear.

The first/last classes were added to avoid the need to target the dynamic classes generated by the component.

[ciampo]

Trying an alternative approach in #55207, hopefully it works well!