Blockbase: Refactor Button Color styles

[jffng]

Changes proposed in this Pull Request:

This PR is an attempt to solve one part of #4435 by lowering the CSS specificity of the button styles. It removes the hover styles for now while we discuss a way forward there.

We discussed a few ideas p1629312308145500/1629295598.131100-slack-C029FM1EH, I'm not sure this is the right approach but wanted to get a feel for the problem and spark a discussion in any case.

To test

• Check out Global Styles: enqueue styles later so theme css can load first WordPress/gutenberg#34147
• Activate blockbase
• Add a button somewhere to a template via the Site Editor
• Change the button's colors (text and background) and save
• Verify those customizations show up correctly in the editor and view
• Go to the post editor
• Add a button, verify you can still use the "Outline" block style variation

Related issue(s):

#4435

[MaggieCabrera]

Thanks for looking into this! I've noticed a couple of things:

First of all this PR breaks the hover on the frontend like this

And also I think we are overriding too many of the styles we define on theme.json with our CSS:

Skatepark theme.json defines:

"styles": {
  "blocks": {
	  "core/button": {
		  "border": {
			  "radius": "var(--wp--custom--button--border--radius)"
		  },
		  "color": {
			  "background": "var(--wp--custom--button--color--background)",
			  "text": "var(--wp--custom--button--color--text)"
		  },
		  "typography": {
			  "fontFamily": "var(--wp--preset--font-family--red-hat-display)",
			  "fontSize": "var(--wp--custom--button--typography--font-size)",
			  "fontWeight": "var(--wp--custom--button--typography--font-weight)",
			  "lineHeight": "var(--wp--custom--button--typography--line-height)",
			  "letterSpacing": "0.1em",
			  "textTransform": "uppercase"
		  }
	  },
  }
}

And we are redefining these values with our button-main-styles mixin. This mixin makes sense for other buttons on the theme that don't have all the controls that the core button has. The search button or the comment form buttons are good examples of why we need this for consistency between all the button son the site, but the core button block doesn't need all that CSS, we should let Global Styles handled that with the theme.json presets. The hover on the other hand, that's not being handled by the editor at all, and we do need the CSS there at the moment.

[jffng]

And also I think we are overriding too many of the styles we define on theme.json with our CSS:

Did you check out this PR WordPress/gutenberg#34147 when testing this? It's needed to make sure that blockbase's CSS doesn't override global styles inline CSS.

The hover on the other hand, that's not being handled by the editor at all, and we do need the CSS there at the moment.

If a user changes the button block colors globally, we do not have a way handling the hover state so it will look broken.

[jffng]

I think this is ready for another review. It removes the button block CSS that was overriding what was already being set by theme.json. It does not require the Gutenberg ordering change above to solve the issue.

Testing instructions

• Activate Blockbase
• Create a post / page and add a button with no styling
• Go to the site editor -> global styles panel and reset to defaults
• Under Root > Color > Color Palette, change the primary color and verify the button's background color changes accordingly in the editor and view.
• Under By Block Type > Button > Color, change the Text and Background color. Verify the changes reflect in the editor and view

[pbking]

Looks like we lost outline styles:

Was this prior:

[pbking]

We seem to have lost control of the ability to style the search button.

[jeyip]

Testing

Requirements

• Per block global styles for the button block respect user customized styles
• Buttons within other blocks are styled as expected

Browsers

• Edge
• Firefox
• Safari
• Chrome

Notes

• I can confirm issues with search button block styling as noted by @pbking

[pbking]

I reworked how this works a little bit and would appreciate another review @jeyip if you are so inclined.

This change doesn't effect the specificity at all, however it does remove from the button block styles anything controlled by Global Styles (leaving only hover state styles applied).

Additionally all "padding" stuff has been removed from the styles and theme.json. I believe this was in place in order to match styles with non-block buttons, however that doesn't appear to be a useful thing after all.

The change seems to cover all of the points raised above with the benefit of simplifying the code in question.

[pbking]

Seeing some problems with padding that I created with the change... working through that.

[pbking]

Ok, dropped this down to the SMALLEST possible change to achieve the desired result.
Color and Typography styles are removed from the Theme's styles for the Button Block.
This allows COLOR and TYPOGRAPHY styles configured in Global Styles to be the only source of color and typography configuration for button BLOCKS.
Non-block buttons continue to be COLORED and .. uh .. TYPOGRAPHICALIZED from custom variables.

GLOBAL PADDING CONFIGURATION OF BUTTONS continues to NOT WORK. Global configurations of padding will be overwritten by the theme due to how OUTLINE STYLES and other theme-specific stylistic concerns for outlines and hover states.

All Blockbase themes have been tested to work.
The file and search blocks have been evaluated to ensure that they continue to work as expected (meaning that they follow semantic colors, not button color configuration).

[jffng]

@pbking I think the golf change here is the right way to go while other issues in Gutenberg are discussed / worked out.

I was unable to test in Skatepark or Quadrat because of Site Editor issues, but Blockbase is looking great.

I noticed a small issue with the search block's button missing a cursor: pointer;, but I don't think that should hold this one up.

🚢

[jffng]

@jeyip

Buttons within other blocks are styled as expected

Just want to make sure we're on the same page — at this time, changing the color of the button block in the global styles panel will not change the color of buttons everywhere (e.g. buttons in forms, the search block, file block). This is not because of anything the theme is doing or can be expected to do. I do agree this is a gap in the experience and should be considered. That discussion is documented a bit here: pNEWy-ecm-p2 and here WordPress/gutenberg#34206

In other words, this PR shouldn't break or create inconsistencies in the default styling of buttons, but it also can't make button colors match when a user makes changes to the button block in the global styles panel.

What do you think? Is there anything else you imagine from this PR before bringing it in?

[jffng]

I gave this one more spin, still working as expected. Going to bring this in as it's a pretty minimal change that solves the issue of global button color styles not being respected. If we need to look at it again we can, thanks everyone.

[jeyip]

I reworked how this works a little bit and would appreciate another review @jeyip if you are so inclined.

Super strange 🤔 Somehow I didn't see the pings. My mistake for missing them, and big thanks to @pbking + @jffng for taking care of this.

I'll be sure to catch up on the code changes and the P2 this afternoon.

[jeyip]

the global styles panel will not change the color of buttons everywhere

What do you think? Is there anything else you imagine from this PR before bringing it in?

I reviewed the work, and I think what y'all have done makes a lot of sense. I'll be sure to communicate the limitations to #cylon.

I do agree this is a gap in the experience and should be considered.

💯 Totally agree with this sentiment. The button block per-block global styling now behaves as expected, but the overall global styling experience itself could use improvement. Thanks for making the corresponding Github issue ⭐