#60293 closed defect (bug) (fixed)
Twenty Fourteen: Table block does not have same design in editor and front.
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.6 | Priority: | normal |
Severity: | minor | Version: | |
Component: | Bundled Theme | Keywords: | has-patch changes-requested commit |
Focuses: | ui, css | Cc: |
Description
Steps to reproduce the issue:-
- Activate Twenty Fourteen Theme.
- Choose a Table block.
- Add some text and Colors.
- Check in the editor side, table border color and the user side both.
In the editor side, we have different border color and when you check front side that border color is different.
Video Url - https://drive.google.com/file/d/1bk2uQX4fkzrvgDQl2IcS6kh0KKap1SMX/view?usp=sharing
Attachments (8)
Change History (28)
#2
@
15 months ago
- Milestone changed from Awaiting Review to 6.6
@nidhidhandhukiya are you able to iterate on this patch as @poena requested? If so it would be great to revisit and see about getting this into the next release - thank you.
#3
@
15 months ago
- Keywords has-patch needs-testing added; changes-requested removed
Updated Patch as per Suggested in above comment.
#4
@
14 months ago
@shailu25 thank you for the patch but it doesn't fully fix what @poena was requesting based on my tests. It only fixes the border color on the editor, not front.
So it would be good to fix that bug, too. -The editor should match the color that is the default color on the front.
I will share an attached image to show what the patch has today. If it can also pick up front and back that would be ideal, thank you.
#5
@
14 months ago
@karmatosed I have Fixed Both Issues in 60293.2.patch
#6
@
14 months ago
- Keywords needs-testing removed
Thank you @shailu25. I can confirm this works in testing. As we are trying to have a unified approach on tables for all themes I am gong to loop in @poena to this issue to get confirmation of the approach. Once we have that we can go ahead with either changes or committing.
#7
@
14 months ago
This is close, I tested it with 6.5.3.
When the striped block style variation is used, the border is visible on the front but not the editor.
I am seeing different behaviors in different themes, so we need to decide what the expected behavior is.
For example in Twenty Twenty, the border is visible in both the editor and front, but on the front the border does not use the text color as the border color...
In Twenty Seventeen, the top and left border never shows on the front, no matter what color setting or style variation that is selected...
#8
@
14 months ago
- Keywords changes-requested added
Looking at the CSS in Gutenberg, the default is to have a transparent border when the striped styled is used:
https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/table/style.scss#L74
So I think the expectation is for it to remain transparent in both the editor and front even when the user changes the text color.
With this PR,
.wp-block-table table[class*="-text-color"] *
overrides the transparent color set by the block:
.wp-block-table.is-style-stripes td, .wp-block-table.is-style-stripes th
#9
@
13 months ago
- Keywords needs-refresh added
Thank you for confirming @poena - let's get a refresh added to this to add that into this PR to have that. @shailu25 are you able to add the changes requested?
#10
@
13 months ago
Sure @karmatosed
I will add suggested changes as per mentioned in above comment.
#11
@
13 months ago
- Keywords changes-requested needs-refresh removed
@karmatosed @poena
I have updated patch as per suggested in above comment.
This ticket was mentioned in Slack in #core-themes by sabernhardt. View the logs.
13 months ago
#14
@
13 months ago
Test Report
Patch tested: 60293.3.patch
Environment
- WordPress: 6.6-alpha-57778-src
- PHP: 8.3.7
- Server: nginx/1.25.4
- Database: mysqli (Server: 8.3.0 / Client: mysqlnd 8.3.7)
- Browser: Chrome 125.0.0.0
- OS: macOS
- Theme: Twenty Fourteen 3.9
- MU Plugins: None activated
- Plugins:
- FakerPress 0.6.6
- Test Reports 1.1.0
Actual Results
- ✅ Issue resolved with patch.
Screenshots
Editor view before patch
Frontend View Before Patch
Frontend View After Patch
#15
@
13 months ago
- Keywords commit added
- Owner set to karmatosed
- Status changed from new to assigned
Assigning to myself to move to commit. Thank you everyone for your collaboration on this so far.
#16
@
13 months ago
Bug Report
Description
Twenty Fourteen: Table block does not have same design in editor and front.
Environment
- WordPress: 6.5.4
- PHP: 8.0
- Server: Apache/2.4.10 (Debian)
- Database: mysqli (Server: 5.5.59-MariaDB-1~wheezy / Client: 5.5.62)
- Browser: Chrome 125.0.0.0 (macOS)
- Theme: Twenty Fourteen 3.9
- MU-Plugins: None activated
- Plugins:
- WordPress Beta Tester 3.5.5
Steps to Reproduce
- Activate Twenty Fourteen Theme.
Choose a Table block.
Add some text and Colors.
Check in the editor side, table border color and the user side both.
In the editor side, we have different border color and when you check front side that border color is different 🐞 Bug occurs.
Expected Results
https://core.trac.wordpress.org/attachment/ticket/60293/60293.3.patch
- Before patch : https://ibb.co/MZPHvdp
After patch : https://ibb.co/4spKjqb ✅
Actual Results
- After patch works smoothly as aspected. ✅
#17
@
13 months ago
- Keywords changes-requested added; needs-testing commit removed
I commented on Slack but failed to update the ticket.
The patch on #60293 could use the
has-text-color
class (and/orhas-background
) instead of theclass*=
I'm also not sure about inheriting border colors. When someone creates a block and sets the text color, matching the border color to the text might be expected. However, anyone who already created a Table or Calendar block with a text color would not expect the border to change in a future update (which typically would increase the contrast).
Testing results
Testing patch https://core.trac.wordpress.org/attachment/ticket/60293/60293.patch
Environment
Actual Results
There is another bug that is not mentioned in the ticket description:
Before the patch, the border color in the editor and front does not match, even when the user does not select a text color.
So it would be good to fix that bug, too. -The editor should match the color that is the default color on the front.