![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#64838 closed defect (bug) (fixed)
Fix: Block pseudo-state styles incorrectly applied to default state
| Reported by: | onemaggie | Owned by: | isabel_brison |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | General | Version: | |
| Severity: | normal | Keywords: | has-patch has-unit-tests gutenberg-merge |
| Cc: | Focuses: |
Description
Backport for https://github.com/WordPress/gutenberg/pull/76326/
What?
When a block defines a custom feature selector in its block.json (e.g. core/button uses .wp-block-button for writingMode rather than the root .wp-block-button .wp-block-button__link), styles set on a pseudo-state like :hover via theme.json were being output under the default-state selector instead of the pseudo-state selector.
Why?
This bug will become more apparent when there's a UI to change the state of the button block after https://github.com/WordPress/gutenberg/pull/75627 lands.
How?
In get_block_nodes, the metadata node for a block pseudo-state was built with the original $feature_selectors (e.g. .wp-block-button) rather than the pseudo-scoped version (e.g. .wp-block-button:hover). The fix builds a $pseudo_feature_selectors array that appends the pseudo-selector to every feature selector string before the node is created.
A test has been added to catch regressions.
Testing Instructions
Add writing mode to a button block on hover in theme.json, check the frontend and you will see the CSS generated:
Before: :root :where(.wp-block-button) { writing-mode: vertical-rl; }
After: :root :where(.wp-block-button:hover) { writing-mode: vertical-rl; }
The unit tests should all pass too.
Change History (7)
This ticket was mentioned in PR #11226 on WordPress/wordpress-develop by @onemaggie.
4 months ago
#1
- Keywords has-patch has-unit-tests added
#2
@
2 weeks ago
- Keywords gutenberg-merge added
- Milestone Awaiting Review → 7.1
This ticket appears to be targeting 7.1, so I will update the milestone.
@onemaggie commented on PR #11226:
2 weeks ago
#3
Closing since the changes are covered by https://github.com/WordPress/wordpress-develop/pull/12253 and https://github.com/WordPress/wordpress-develop/pull/11706
@onemaggie commented on PR #11226:
13 days ago
#4
On second though I'll reopen this because the backport is already registered to this ticket and it's worth it keeping the test in
@onemaggie commented on PR #11226:
13 days ago
#5
/cc @tellthemachines if you could have a look?
@onemaggie commented on PR #11226:
7 days ago
#7
@tellthemachines thank you kindly
Backport for https://github.com/WordPress/gutenberg/pull/76326/
Core trac ticket: https://core.trac.wordpress.org/ticket/64838
## What?
## Why?
This bug will become more apparent when there's a UI to change the state of the button block after https://github.com/WordPress/gutenberg/pull/75627 lands.
## How?
We have added a test to catch this problem should there be a regression
## Testing Instructions
Add writing mode to a button block on hover on theme.json, check the frontend and you will see the CSS generated:
Before:
After:
The unit tests should all pass too