Opened 10 months ago
Closed 6 months ago
#60614 closed defect (bug) (fixed)
Button block's Outline style does not have border in non-framed editor
Reported by: | viralsampat | Owned by: | |
---|---|---|---|
Milestone: | 6.6 | Priority: | normal |
Severity: | normal | Version: | 6.5 |
Component: | Editor | Keywords: | dev-feedback |
Focuses: | ui, css | Cc: |
Description
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,
Attachments (5)
Change History (36)
#2
@
10 months ago
Outline is working fine here on both editor and frontend. You can check the conflict with other plugin.
#3
@
10 months ago
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,
#4
@
10 months ago
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
#5
@
10 months ago
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
#6
@
10 months ago
- Version changed from 6.4.3 to trunk
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
.
- Activate Twenty Twenty-Two.
- Create a new post.
- 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.
- Add at least two Buttons blocks to your post: one with default colors and one with special color choices in the sidebar.
- Save and preview.
#7
@
9 months ago
- Milestone changed from Awaiting Review to 6.5
Based on @sabernhardt's report, I'm moving this to 6.5 for visibility.
This ticket was mentioned in Slack in #core-editor by swissspidy. View the logs.
9 months ago
#9
@
9 months ago
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; }
#10
@
9 months ago
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.
#11
@
9 months ago
And same with https://core.trac.wordpress.org/ticket/60280, which was the first change I tried reverting.
#12
@
9 months ago
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); }
#13
@
9 months ago
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)" }
#14
@
9 months ago
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.
#15
@
9 months ago
- Component changed from Bundled Theme to Editor
- Summary changed from Twenty Twenty-Two: The button block border does not appear on the editor side. to Button block's Outline style does not have border in non-framed editor
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.
#16
@
9 months ago
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
#17
@
9 months ago
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?
#18
@
9 months ago
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.
#19
@
9 months ago
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.
#20
@
9 months ago
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
#21
@
9 months ago
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.
#23
@
9 months ago
@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.
This ticket was mentioned in Slack in #core by jorbin. View the logs.
8 months ago
#25
@
8 months ago
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
- ✅ Working
#26
@
8 months ago
@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.
#27
@
8 months ago
@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.
#28
@
8 months ago
- Milestone changed from 6.5.1 to 6.6
I do not recommend changing the selector specificity in a minor release.
This ticket was mentioned in Slack in #core by nhrrob. View the logs.
6 months ago
This ticket was mentioned in Slack in #core-editor by nhrrob. View the logs.
6 months ago
#31
@
6 months ago
- Resolution set to fixed
- Status changed from new to closed
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!
Back-end