-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Button block styling broken in editor and on front end due to change in markup #21917
Comments
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:
What do you suggest as a different process/flow here? |
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. |
Maybe a different workflow / process would be to convert everything you broke with a new radical update? |
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
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
The text was updated successfully, but these errors were encountered: