Button block styling broken in editor and on front end due to change in markup

[dreamwhisper]

Describe the bug
The changes in #21266 have resulted in button styles being broken in our Genesis child themes designed around the block editor.

The markup has changed to remove a div wrapper from the button block and is automatically updated when editing a post. As a result, any styles written as .wp-block-button .wp-block-button__link will no longer apply because the .wp-block-button is moved to the link. New CSS would either need to drop the .wp-block-button or be written as .wp-block-button.wp-block-button__link.

In some themes, style variations rely upon the .wp-block-button__link having the .wp-block-button div wrapper for pseudo class styles.

To reproduce

1. Install https://github.com/studiopress/genesis-sample/archive/develop.zip with WordPress 5.4. (requires Genesis parent theme - happy to supply directly, if needed.)
2. Activate the theme.
3. Add the content below to the code editor, switch to visual, then save.
4. Activate Gutenberg 7.9.1.
5. Edit and update the page.
6. Note that the markup is updated in the editor and the front end.

The button appearance changes from this:

to this:

Expected behavior
Markup changes will be backward compatible with existing themes. As we embrace the editor in designs and work to expand usage, changes to markup and classes impact user experience as well as maintenance for theme developers.

If this were an editor only problem, the issue would be less concerning, but this will impact the front-end of user sites without warning since the markup automatically updates when editing.

Screenshots

Additional front-end examples are below.

WordPress 5.4:

Gutenberg 7.9.1:

Button variation in 5.4:

Gutenberg 7.9.1:

Editor version (please complete the following information):

WordPress version: 5.4
Gutenberg plugin: 7.9.1

Desktop (please complete the following information):

OS: MacOS
Browser: Chrome
Version: 81

Related to:

#21747
#21642
#21707
#21685
#21909

Additional context
Impacts StudioPress Genesis child themes with specific Gutenberg editor styling and which do not have an automated update process. It has the potential to impact more than 34,000 sites running StudioPress themes and an unknown number of themes sold by other developers which use .wp-block-button .wp-block-button__link for styling.

CC: @youknowriad

[youknowriad]

Hi There!

I agree that markup changes are an issue and that we try to minimize these as much as we can and we do but as with everything in development, we do mistakes, for instance the "div" wrapper on the button block was a mistake; It's useless, the markup was not semantic so it needed to be fixed so we made the decision to:

• release the updated markup on the Gutenberg Plugin (dev plugin)
• Try to minimize the markup change as much as we can and try to maximize the backward compatibility by retaining the useless wp-block-button__link classname and make it easy to style both markup versions at the same time.
• warn the theme authors on the release post about the upcoming markup change.
• plan to write a dev note about it for the upcoming WordPress 5.5 release.

What do you suggest as a different process/flow here?

[dreamwhisper]

Thanks for taking a look at this and, at least temporarily, reverting the button markup change @youknowriad.

Reviewing and updating themes to catch changes in an upcoming release takes a considerable amount of time so I appreciate the communication plan for any change that could impact themes. Updating due to class or markup changes is a significant amount of maintenance. We plan to review our themes to simplify where possible as you suggest, though those changes wouldn't apply retroactively to existing sites.

I still have concerns that the user experience is not ideal when updating since there is no notification that content will change and the user is unexpectedly presented with perceived "broken" page content. If there was a way to minimize the amount of breaking changes caused by block markup alterations (more detailed reviews up front? a block markup standard or API?) or a better UX when breaking changes may occur (notifications of some type? quick option to revert?), that seems worth pursuing.

[mitchellkrogza]

I am having major problems too. Only discovered today that WordPress buttons I added to endless blog posts just display a crappy link on the front end while they display in the editor? What on earth has happened to break every single button I had across over 100 blog posts?

And also on WooCommerce product blocks no buy now buttons for any products are displaying but in the backend it display a black blob. How can this all get so messed up?

[mitchellkrogza]

Hi There!

I agree that markup changes are an issue and that we try to minimize these as much as we can and we do but as with everything in development, we do mistakes, for instance the "div" wrapper on the button block was a mistake; It's useless, the markup was not semantic so it needed to be fixed so we made the decision to:

• release the updated markup on the Gutenberg Plugin (dev plugin)
• Try to minimize the markup change as much as we can and try to maximize the backward compatibility by retaining the useless wp-block-button__link classname and make it easy to style both markup versions at the same time.
• warn the theme authors on the release post about the upcoming markup change.
• plan to write a dev note about it for the upcoming WordPress 5.5 release.

What do you suggest as a different process/flow here?

Maybe a different workflow / process would be to convert everything you broke with a new radical update?