Color controls: take labels from block supports #29155
Conversation
oandregal
added
the
Global Styles
|
Size Change: +84 B (0%) Total Size: 1.38 MB
ℹ️ View Unchanged
|
|
This PR adds some strings for the UI in the block.json, see issue description. The idea would be allowing things like: So far, we haven't added anything to block.json that needed to be translated. If we do this, these strings won't be translated, so blocks that use this mechanism will show untranslated strings for the color UI controls ― for context, I expect this to be used only in the social links block. Are we ok landing this as it is? Or would we rather have the translation mechanism ready first? An alternative to unblock this from landing would be to store the labels elsewhere, as with the block's title and description, for example. |
oandregal
added
the
Internationalization (i18n)
IMO we should first have an idea of how translations will be handled in theme.json first... {
"translations": {
"textDomain": "my-theme",
"labels": {
"__experimentalBackgroundColorLabel": "Background Label",
"__experimentalLinkColorLabel": "Link Label",
"__experimentalTextColorLabel": "Text Label"
},
"templateStrings": {
"builtWith": "Built with My-Theme",
"poweredBy": "Powered by WordPress"
}
}
}But until we know how translations will be handled in theme.json, adding anything feels a bit premature... |
Uhm.. block keywords, block name, description and style names are all translatable and picked up by WP-CLI already. But if you plan on adding a bunch of additional translatable fields then you'd really want to have a schema for it too.
For |
Can you think of other use cases besides Social Links? |
Haven't done an audit for all blocks, but some come to mind: Cover (it's called overlay, but it sets a background-color), Pullquote (uses "main" for border-color and "text" for color), Separator (uses "color" for border-color). |
|
Would it be too much abstraction to totally remove all semantics from these colors (in the code) and simple have color 1, color 2, ...? This would let the block define how to implement these colors so they could be used more flexibly. It would also open the door to having more than 3 colors... |
Figuring out how each hook can have different labels is a first step in making them more abstract :) Whether we should remove all semantics from the properties (color1 instead of textColor) I'm not so sure. With what we have we aim to cover (almost?) all the core blocks use cases. |
|
I think customizing labels should not be exposed in block config but be something you do in But any further customization of the UI should happen in the edit function which is more expressive and less convoluted than a ton of indirect options. The supports should be kept as simple as possible, otherwise it will balloon as an API. |
|
I came to the same conclusion upon some investigation. In the case of Social Links block, we have not only a custom label, but also non-standard names for the color and background color: <!-- wp:social-links {"iconColor":"white","iconColorValue":"#FFFFFF","iconBackgroundColor":"dark-gray","iconBackgroundColorValue":"#28303D"} -->In general, it makes it fit into the current architecture of block editor hooks for blocks:
|
I agreed, up until I took a stab. When I did, I found it completely redundant to call the inspector panel "Color settings". So I changed the panel title to simply "Color", and in doing so it felt wrong to have a duplicate "Color" for the icon right below. But color plus icon color felt right. More in #30075 |
|
Going to close this one. The next steps for this look like aligning the current labels (for the auto-generated controls generated for the hooks + the existing custom controls) #30075 If, in the future, we wanted to offer the possibility of custom labels for the UI controls generated by the hooks, it should be explored to be done via filters in |
This PR is part of #28913 and follows-up to #29142 (comment)
It allows the blocks to set the labels they want to use in the UI components for the color hook: text, background (includes gradients), and link. If they're not present, it fallbacks to the current strings ("Text Color", "Background Color", "Link Color").
This is useful to support use cases such as the social links, in which the color and background properties want to be advertised as "Icon color" and "Icon background color".
How has this been tested?
colorsection of the paragraph's block.json to be:Note that this only affects the block sidebar, but not the "global styles" sidebar. I'd like to address that in a follow-up PR.