Size Change: -6 B (0%)

Total Size: 1.41 MB

_{compressed-size-action}

That does actually make sense. Thanks.

I'm thinking about how to generalize those labels so we could have a more structured approach when injecting UI controls with supports in the block definition. The most common causes are:

• text
• background
• link

There are exceptions like the Button block and Social Links block where we have quite a unique approach:

• icon's outer part (aka icon background color) and icon's inner part (aka icon color)
• buttons outer part (aka background color) and the text (aka text color)

I think it's a bit confusing in the Button block and it shouldn't use the name background since it's different from the background you know from the Group or Heading blocks. Should we use a consistent naming that would work for both those blocks and better express the intent like Inner color and Outer color? This way, we would be able to use 5 different types of color in supports that might cover 99% of cases. @mtias and @nosolosw, I would like to hear your thoughts as well.

Could we use "Item background"?

Could we use "Item background"?

Yes, item background and item foreground would work as well 👍🏻

👋 If the same label names in the color hook can be the same in use for all the blocks (including social links) we won't need to implement #29155 (it was created because in #28913 we wanted to migrate some blocks -including social links- to use the block support mechanism instead of the custom controls and labels).

@nosolosw, it might be as simple as extending what you can see for links in the Paragraph block:

For the Social Links block you could have:

"supports": {
    "color": {
        "foregroundItem": true,
        "backgroundItem": true
    }
}

and we would only need to extend the handling in the color hooks in the block editor package.

Feel free to push any changes to this PR if that's helpful.

We can also separate things out, as this PR touches a slew of other things.

Let's agree on the direction first, I don't know if what I propose makes sense with everything else that already exists 😄

@gziolo To make sure I follow, there're two things here:

1. For the labels, we don't need to rename anything in the block supports. If we can use the same labels in the hook and in the custom controls, we don't need anything else for #28913

2. The other thing you seem to be hinting at is that we should also rename the names of the block supports for colors so that:

• text => foregroundItem
• background => backgroundItem

Is that correct? If we were to rename them, I'd think we'd want text to become color and background to be backgroundColor. The other block supports (fontSize, lineHeight, border, etc) have the same name of the CSS property they represent and I guess these should be the same. gradients represents background, thought, so I suppose it could be renamed as well although gradients is fine by me. Finaly, link is being moved out of block supports to become an element of the block as per #29891

Does this help?