Button block's Outline style does not have border in non-framed editor

[viralsampat]

Hello,

I have reviewed the button block and found that the button "outline" does not appear on the editor side.

Here, I have attached its screenshots:

Environment info

---

Device: Macbook M1
OS: 14.3.1 (23D60)
Browser: Google Chrome
Version 121.0.6167.184 (Official Build) (arm64)
WordPress version: 6.4.3 running, Gutenberg 17.7.0, Theme active: Twenty Twenty-Two,

Thanks,

[viralsampat]

Back-end

[viralsampat]

Front-end

[simrandeep]

Outline is working fine here on both editor and frontend. You can check the conflict with other plugin.

[viralsampat]

Hello @simrandeep

Thank you so much for your feedback.

I have rechecked the issue and still I am getting this issue. I have installed only one Gutenberg plugin and have not used any other plugin.

Here, I have provided the video for the same.

Issue video: ​https://share.cleanshot.com/T36Bjjc3QN4WHB2L3CGR

If I am doing something wrong then please make me correct here.

Thanks,

[poena]

Please test without Gutenberg, it may be a problem with Gutenberg.

If possible, please also test with WordPress 6.5 Beta. It maybe already have been solved with the new version.
​https://make.wordpress.org/test/2024/02/15/help-test-wordpress-6-5-beta-1/#test-environment-installation

[harshalkadu]

Hi @viralsampat @poena

I have retested this issue on the latest WordPress beta version, 6.5 beta 2, and I won't be able to reproduce it. Kindly check the attached screenshots below. 

BE SS: ​https://prnt.sc/2buHY9450V1W
FE SS: ​https://prnt.sc/pKAvwk_TY0Pr

Device: Macbook Pro
OS: 14.1.1 (23D60)
Browser: Google Chrome
Version 122.0.6261.57 (Official Build) (x86_64)
WordPress version: 6.5 beta 2 Theme active: Twenty Twenty-Four
SS: ​https://prnt.sc/QUlKCJcn6Dgu

[sabernhardt]

Outline style in WordPress 6.4

[sabernhardt]

Outline style in WordPress 6.5 Beta 3 lacks border and can have the wrong colors

[sabernhardt]

I see the issue in WordPress 6.5 beta 3 with the non-framed editor, but not with the iframe (nor in 6.4 with either editor). In addition to the Outline style's missing border, the default colors match the Fill style. The specificity of the Button block styles with .editor-styles-wrapper overrides .is-style-outline rules in block-library/style.css.

1. Activate Twenty Twenty-Two.
2. Create a new post.
3. If you do not have the Custom Fields panel at the bottom, open the 3-dot Options menu and go to Preferences. Then find the Custom Fields toggle switch (now under General->Advanced), turn it on, and click the "Show & Reload Page" button.
4. Add at least two Buttons blocks to your post: one with default colors and one with special color choices in the sidebar.
5. Save and preview.

[jorbin]

Based on @sabernhardt's report, I'm moving this to 6.5 for visibility.

[poena]

In 6.5 RC2, with the custom fields panel off, this is the order of the CSS:

element.style {
	white-space: pre-wrap;
	min-width: 1px;
}

block-library/style.css

.wp-block-button .wp-block-button__link:where(.is-style-outline):not(.has-background),
.wp-block-button:where(.is-style-outline)>.wp-block-button__link:not(.has-background) {
	background-color: initial;
	background-image: none;
}

block-library/style.css

.wp-block-button .wp-block-button__link:where(.is-style-outline):not(.has-text-color), .wp-block-button:where(.is-style-outline)>.wp-block-button__link:not(.has-text-color) {
	color: currentColor;
}

<style>

.wp-block-button .wp-block-button__link {
	**THIS LINE IS OVERWRITTEN** background-color: var(--wp--preset--color--primary);
	border-radius: 0;
	**THIS LINE IS OVERWRITTEN** color: var(--wp--preset--color--background);
	font-size: var(--wp--preset--font-size--medium);
}

In 6.5 RC2, with the custom fields panel present, this is the order of the CSS:

element.style {
	white-space: pre-wrap;
	min-width: 1px;
}

<style>

.editor-styles-wrapper .wp-block-button .wp-block-button__link {
	background-color: var(--wp--preset--color--primary);
	border-radius: 0;
	color: var(--wp--preset--color--background);
	font-size: var(--wp--preset--font-size--medium);
}

block-library/style.css

.wp-block-button .wp-block-button__link:where(.is-style-outline):not(.has-background),
.wp-block-button:where(.is-style-outline)>.wp-block-button__link:not(.has-background) {
	**THIS LINE IS OVERWRITTEN** background-color: initial; 
	background-image: none;
}

block-library/style.css

.wp-block-button .wp-block-button__link:where(.is-style-outline):not(.has-text-color), .wp-block-button:where(.is-style-outline)>.wp-block-button__link:not(.has-text-color) {
	**THIS LINE IS OVERWRITTEN**color: currentColor;
}

<style>

.editor-styles-wrapper .wp-element-button,
.editor-styles-wrapper .wp-block-button__link {
	**THIS LINE IS OVERWRITTEN** background-color: #32373c;
	border-width: 0;
	**THIS LINE IS OVERWRITTEN** color: #fff;
	font-family: inherit;
	**THIS LINE IS OVERWRITTEN** font-size: inherit;
	line-height: inherit;
	padding: calc(0.667em + 2px) calc(1.333em + 2px);
	text-decoration: none;
}

[poena]

I'm trying to check if it is related to https://core.trac.wordpress.org/ticket/60453, or https://core.trac.wordpress.org/ticket/60312, I tried reverting but I don't see any difference.

[poena]

And same with https://core.trac.wordpress.org/ticket/60280, which was the first change I tried reverting.

[poena]

Besides the order and the where, the background CSS is also different compared to in 6.4. Here the background-color was transparent, not initial.

6.4, with the custom fields panel enabled:

element.style {
	white-space: pre-wrap;
	min-width: 1px;
}
.wp-block-button .wp-block-button__link.is-style-outline:not(.has-background),
.wp-block-button.is-style-outline>.wp-block-button__link:not(.has-background) {
	background-color: transparent;
	background-image: none;
}
.wp-block-button .wp-block-button__link.is-style-outline:not(.has-text-color),
.wp-block-button.is-style-outline>.wp-block-button__link:not(.has-text-color) {
	color: currentColor;
}
<style>
.editor-styles-wrapper .wp-block-button .wp-block-button__link {
	background-color: var(--wp--preset--color--primary);
	border-radius: 0;
	color: var(--wp--preset--color--background);
	font-size: var(--wp--preset--font-size--medium);
}

[poena]

And this is the current CSS ​in the block's style.scss in the Gutenberg GitHub repository:

.wp-block-button:where(.is-style-outline) > .wp-block-button__link:not(.has-background),
.wp-block-button .wp-block-button__link:where(.is-style-outline):not(.has-background) {
	background-color: transparent;
	// background-image is required to overwrite a gradient background
	background-image: none;
}

And the theme.json:

blocks": {
	"core/button": {
		"border": {
	 		"radius": "0"
		},
		"color": {
			"background": "var(--wp--preset--color--primary)",
			"text": "var(--wp--preset--color--background)"
		}

[isabel_brison]

When the editor isn't iframed, core global styles are still prefixed with .editor-styles-wrapper, which increases the specificity relative to the iframed version and causes the border: 0 rule here: ​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/theme.json#L308 to override the style variation.

Reverting #60312 didn't make a difference because that change is just for the server-side; the corresponding JS change went in with all the npm package updates.

The global specificity reduction in progress in ​https://github.com/WordPress/gutenberg/pull/57841 will fix this issue in the next release; in the meantime I'm not sure what the best temporary patch should be.

[sabernhardt]

The missing border also occurs with Twenty Twenty-Three, but its colors are correct (except for the :hover state). Twenty Twenty-Four specifies its own border for the Outline style, so that works.

If it's still safe to revert the change that caused this regression, that might avoid any additional bugs we simply have not found. However, this is the only bug I know was created by the change, and the situation could be rather uncommon.

• Plugins such as Yoast SEO increase the non-framed editor usage, so it affects more than just the people who show the Custom Fields panel, though the iframe editor is probably used by a much larger number of sites.
• This does not affect all block themes (yet two out of three bundled themes is the majority of a small, popular sample).
• Outline is not the default style option for the Button block.
• Anyone who has added an Outline button-style link earlier in the same theme could be surprised by the difference in 6.5, but then the preview would show it correctly.
• If a user has not chosen the Outline style yet, the missing border and/or incorrect colors would make that option less appealing to select.

If GB57841 is the preferred course for moving forward, I think it could help to commit/sync that to 6.6-trunk early for wider testing toward the major release.

[poena]

Personally I would not consider this a blocker for 6.5, but reverting it in the next package update would be preferred, if not too much trouble this late.
@isabel_brison @youknowriad @get_dave

[youknowriad]

So If I'm reading this properly. Reverting ​https://github.com/WordPress/gutenberg/pull/57659 entirely would solve the issue right? What would be the downsides of the revert, what bugs will we be introducing again?

It seems GB57659 can land at the same time as GB57841 in 6.6 no?

[isabel_brison]

From my reading of ​https://github.com/WordPress/gutenberg/issues/49835 it seems there were no actual bugs related to the more specific style variation selector, so reverting shouldn't cause issues. I guess if we did revert, we'd also have to revert https://core.trac.wordpress.org/changeset/57490 for the selector to match across editor and front end.

Could it be done just in the 6.5 release branch? Work on specificity reduction is ongoing so ideally we'd keep the change in trunk as the bug will be fixed by the follow-ups.

[youknowriad]

I think for Gutenberg it's fine to do the revert only in 6.5 branch but I'm not sure about Core. Maybe @swissspidy knows.

[youknowriad]

Also, it looks like the revert is not that simple because of this fix, (the revert need to restore the old code but keep this fix somehow) ​https://github.com/WordPress/gutenberg/commit/8895a51595249d8edf68e83428fac182c89583b6

[swissspidy]

I think for Gutenberg it's fine to do the revert only in 6.5 branch but I'm not sure about Core

It's possible for sure, but I just want to better understand how big of a code change we're talking here. And are the follow-ups expected to land very soon and thus warranting not reverting it in trunk right now?

If there's more details or a PR / patch to look at that would help understand the code a bit better.

If it's not a blocker for release we should consider just fixing this in 6.5.1 instead.

[isabel_brison]

@swissspidy the follow-ups are expected to land soon, the crucial one being ​https://github.com/WordPress/gutenberg/pull/60106, so potentially once it's merged we could consider an early alpha package update in trunk.

There's also a strong candidate in ​https://github.com/WordPress/gutenberg/pull/56649 for patching the issue in 6.5.1 as it's a much smaller and less impactful change.

[devsahadat]

Working fine for me

[devsahadat]

Working fine for me. Not able to reproduce the issue.

Environment

• WordPress: 6.5
• PHP: 8.1.23
• Server: Apache/2.4.43 (Unix)
• Database: mysqli (Server: 8.0.16 / Client: mysqlnd 8.1.23)
• Browser: Chrome 123.0.0.0 (macOS)
• Theme: Twenty Twenty-Two 1.7
• MU-Plugins: None activated
• Plugins:
  • WordPress Beta Tester 3.5.5

Results

1. ✅ Working

[isabel_brison]

@devsahadat in order to reproduce the issue, you need to enable custom fields under Options > Preferences in the post editor. The issue is still reproducible in 6.5 and core trunk.

The proposed fix that's most suitable for a minor release is still under review: ​https://github.com/WordPress/gutenberg/pull/56649.

[devsahadat]

@isabel_brison Thanks for your clarification. Yeah i am able to reproduce the issue on WordPress 6.5 . If i enable custom fields, Button border not showing on editor but in frontend its showing.

[sabernhardt]

I do not recommend changing the selector specificity in a minor release.

[isabel_brison]

I can no longer reproduce this issue on trunk. The specificity of global styles selectors was changed in #61165, which fixed this as a side effect :)

Closing the ticket for now but feel free to reopen if the problem persists!