Gutenberg: Button preview doesn't match styling

Created on 28 Apr 2020  Â·  5Comments  Â·  Source: WordPress/gutenberg

Describe the bug
The style preview for buttons no longer matches the button being edited.

To reproduce
Steps to reproduce the behavior:

  1. Install current master branch.
  2. Add a button to the page.
  3. Check the previews to see if the button matches.

Note: it never matched custom color selections or border radius option, only the default.

Expected behavior
Button previews will match the button style.

Screenshots
If applicable, add screenshots to help explain your problem.

WordPress 5.4
Screen Shot 2020-04-28 at 2 31 29 PM

Master
Screen Shot 2020-04-28 at 2 30 47 PM

7.9.1
Screen Shot 2020-04-28 at 2 34 36 PM

Editor version (please complete the following information):

  • WordPress version: 5.4
  • Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? yes
  • If the Gutenberg plugin is installed, which version is it?
  • Current master branch, but also noticed with 7.9.1

Desktop (please complete the following information):

  • OS: Mac
  • Browser: Chrome
  • Version: 81

Additional context

[Block] Buttons [Type] Bug

Most helpful comment

@dreamwhisper thanks for reporting this! Good catch. I tested this and was able to replicate with Gutenberg 7.9.1:

Screen Shot 2020-04-28 at 2 37 50 PM

Here's a video showing the entire experience: https://cloudup.com/cEoSvU-JI5M Oddly, it displays properly after publishing!

All 5 comments

@dreamwhisper thanks for reporting this! Good catch. I tested this and was able to replicate with Gutenberg 7.9.1:

Screen Shot 2020-04-28 at 2 37 50 PM

Here's a video showing the entire experience: https://cloudup.com/cEoSvU-JI5M Oddly, it displays properly after publishing!

@youknowriad will this revert https://github.com/WordPress/gutenberg/pull/21923 resolve the above?

Potentially, but this is more complex than it seems:

The "example" used in the previews use a "green" background color. So in theory, this color should be visible no matter the variation unless the CSS of the style variations has a higher specificity. So technically, showing the background color or not in the preview is not a bug either way, it's a choice made by the "style variation" to support custom backgrounds or not.

The revert might have changed the specificity causing the background to not be applied anymore.

It's a small item in the grand scheme of things, but is there a reason for using the "green" vivid-green-cyan-background-color background color in previews with has-background?

5.4 markup is this:

<div class="wp-block-button is-style-fill">
<div role="textbox" aria-multiline="true" aria-label="Add text…" class="rich-text block-editor-rich-text__editable wp-block-button__link" contenteditable="false" style="white-space: pre-wrap;">Call to Action</div>
</div>

vs

<div aria-label="Add text…" role="textbox" class="wp-block-button is-style-fill wp-block block-editor-block-list__block rich-text block-editor-rich-text__editable wp-block-button__link has-vivid-green-cyan-background-color has-background" aria-multiline="true" contenteditable="false" id="block-fdc6ef1a-0f8e-4b7a-acee-b5863f32c405" data-block="fdc6ef1a-0f8e-4b7a-acee-b5863f32c405" data-type="core/button" data-title="Button" style="white-space: pre-wrap; transform-origin: center center;">Call to Action</div>

The color is not correct for our default button because vivid-green-cyan-background-color and has-background are added to the preview. The theme does not include the vivid-green-cyan-background-color in the color palette and the button doesn't have a background (has-background).

@dreamwhisper that color should definitely be removed from the "example" of the Button block because it's not theme agnostic. We could replace it with a custom color instead of a palette color.

Was this page helpful?
0 / 5 - 0 ratings