Design Tools: adding button element support results in unfixable blue border & no padding in heading element

[annezazu]

In trying to use #53667, I'm noticing two odd issues with WP 6.3.1, GB 16.7 RC1, and TT3. The first is that when adding button element controls, I cannot get rid of a strange blue border around the button. I am not sure where it's coming from. To replicate, create a Group block > set element styling for Buttons block > add a buttons block.

blue.border.around.buttons.mov

Second, if I add heading support, no padding is added resulting in an underwhelming view and I different experience than if I add background color support to a heading block:

Screen.Recording.2023-09-20.at.2.44.05.PM.mov

Perhaps this is within the current expectations for what made it into 6.4 but wanted to open an issue regardless as this isn't functioning how I expected, especially for the Buttons block. @aaronrobertshaw

[aaronrobertshaw]

👍 Thanks for flagging this @annezazu, there are some tricky nuances to explain here but I'll give it a go!

The first is that when adding button element controls, I cannot get rid of a strange blue border around the button. I am not sure where it's coming from.

I can't replicate this blue border with TwentyTwentyThree except if I set the button Block Style to "Outline", then select a blue text color for the button.

In the demo video of the issue the button element always has a background and text color set so I can't be sure if the buttons are using that outline block style or not. Would it be possible to share which theme you are using and perhaps the block markup from the code editor view as well?

The support added in #53667 was for button and heading element colors. My apologies for not emphasizing that more strongly in the PR title and description. You can think of the support added for button and heading elements as the same as for links.

The fact it is color support is why they are selected from the color panel's menu. They don't add any further styles such as borders or outlines. That's why I suspect what you are seeing might be theme-related.

Second, if I add heading support, no padding is added resulting in an underwhelming view and I different experience than if I add background color support to a heading block: ... Perhaps this is within the current expectations for what made it into 6.4

As touched on above, the it was color support for button and heading elements that was added. So adjusting these element colors will only add color styles.

There are some general styles that get applied to block instances. One of those I believe is the padding your refer to when a block gets color support added to it and has the .has-background class applied. The difference here is we are styling an element generally within the section or block, not block instances themselves like the heading block.

The sort of full control over styling elements I think you were expecting is on the cards but this was an interim step towards that.

There are two related efforts underway (though not for 6.4) that would provide the desired levels of control, element variations and section-specific theme.json.

The best source of info on element variations is probably #48581. While that specific issue demos what element variations would look like for colors, the concept would extend to typography, spacing etc. as well and has been discussed along those lines too.

For section-specific theme.json, you'd be able to define a full set of block styles for a Heading block instance within a section as opposed to just heading elements. This would give you similar control for a section of the page as Global Styles does for a block type across the site.

Both of those features might be some time away as they require some thought on the UI and UX front from our talented designers. For what it is worth, I have explored the generation of section-specific block type styles recently via theme.json code added directly to the block markup and that side of it should work rather well.

🤞 I hope all that helps clarify the expected behaviour when defining colors on button and heading elements.

I'd like also to reinforce that the lack of padding control around a heading with background color isn't ideal and using the background color on heading elements might only be useful for headings that have some padding already applied to them. We are moving in the direction to address this though.

Screen.Recording.2023-09-21.at.12.15.42.pm.mp4

[annezazu]

In the demo video of the issue the button element always has a background and text color set so I can't be sure if the buttons are using that outline block style or not. Would it be possible to share which theme you are using and perhaps the block markup from the code editor view as well?

Using TT3 (Twenty Twenty-Three) with the Electric style variation. Here's the markup:

<!-- wp:group {"style":{"elements":{"button":{"color":{"text":"var:preset|color|vivid-red","background":"var:preset|color|white"}}}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:buttons -->
<div class="wp-block-buttons"><!-- wp:button -->
<div class="wp-block-button"><a class="wp-block-button__link wp-element-button">Test</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons --></div>
<!-- /wp:group -->

Both of those features might be some time away as they require some thought on the UI and UX front from our talented designers. For what it is worth, I have explored the generation of section-specific block type styles recently via theme.json code added directly to the block markup and that side of it should work rather well.

Thanks so much for talking this all through. I definitely have been paying attention to the section specific theme.json work and my instincts were that this was perhaps a more meaningful step in that direction that at first glance. This still does unlock some neat styling considerations but with caveats and limitations it sounds like.

Happy to close out if the above is expected behavior and related to the default theme style variation I'm using.

[aaronrobertshaw]

Thank you @annezazu for taking the time to clarify that for me and provide the block markup 🙇

I can confirm the border you are seeing is applied on button elements globally by the Electric style variation for TT3. You can see exactly were via the link below:

https://themes.trac.wordpress.org/browser/twentytwentythree/1.2/styles/electric.json#L39

Currently, the ability to style borders on elements isn't provided via Global Styles either so the only way to remove that would be to create a customized version of Electric's theme.json or add some custom CSS to reset that border. If you intended to only remove the border in a specific section not global that becomes a little more involved as well.

Unfortunately, this is one of the downsides of element styles being used rather than global styles on block types. The flip side to that is that not every button in every block is a button block type so there is a place for element styles. The balance between the two can be a moving target though.

I definitely have been paying attention to the section-specific theme.json work and my instincts were that this was perhaps a more meaningful step in that direction that at first glance.

Understandable 🙂

There will be a LOT of UI work required to implement section-specific styling of block types. The element color sets (a.k.a. element variations) will require similar work. As such there is some discussion going on around a possible refresh of the information architecture within the global styles panel and how that might enable the broader features you were looking for.

For the time being, however, allowing colors on additional elements is a small step that might help inform our future efforts.

This still does unlock some neat styling considerations but with caveats and limitations it sounds like.

Exactly, it's another tool in the kit designers might leverage to add some nice touches but isn't a silver bullet.

Happy to close out if the above is expected behavior and related to the default theme style variation I'm using.

I appreciate the opportunity to give this functionality another fresh look. The behaviour is expected given its intended scope so my vote would be to close this issue and shift any further discussion to the dedicated section specific styling issues or the PRs that spring from those.

[aaronrobertshaw]

In light of the discussion above, I'll close this issue now. Please feel free to reopen it if desired.

[annezazu]

Thanks for the detailed explanation and the patience :) Once I read your response, I knew it wasn't a bug nor something to prioritize for beta 1 so moved on temporarily.