Context Navigation

← Previous Ticket
Next Ticket →

#65436 closed defect (bug) (reported-upstream)

Block style variation partial for core/button emits non-matching nested element selector in editor and Stylebook previews

Reported by:	kimjiwoon	Owned by:
Priority:	normal	Milestone:
Component:	Editor	Version:	7.0
Severity:	normal	Keywords:	needs-patch reporter-feedback
Cc:		Focuses:	ui, css

Description

When a block style variation for core/button is registered via a theme.json partial (/styles/blocks/*.json) and styles the nested elements.button, the front end can render correctly, but the post editor canvas and Global Styles / Stylebook preview emit selectors that do not match the actual Button block markup.

The generated selector treats .wp-block-button__link and .wp-element-button as nested descendants:

.wp-block-button.is-style-tonal .wp-block-button__link .wp-element-button

But the Button block markup puts both classes on the same element:

<div class="wp-block-button is-style-tonal">
    <a class="wp-block-button__link wp-element-button">Tonal button</a>
</div>

So the selector never matches in the editor canvas / Stylebook preview, and the button falls back to the default Filled button styles. On the front end, the style engine appears to add a generated variation class (for example .is-style-tonal--3) and emits selectors that do match, so the bug can be hidden on the front end while still breaking authoring previews.

Environment

WordPress: 7.0 (wp-env, WordPress/WordPress#7.0)
Theme: Axismundi 0.1.0
Browser observed: Chromium/Chrome
Active plugins in the local env: Create Block Theme, Theme Check, Axismundi Theme Switcher (not involved in this block rendering issue)

Minimal theme.json partial shape

A block style variation partial like this auto-registers the variation and appears in the editor UI:

{
    "$schema": "https://schemas.wp.org/wp/7.0/theme.json",
    "version": 3,
    "title": "Tonal",
    "slug": "tonal",
    "blockTypes": [ "core/button" ],
    "styles": {
        "elements": {
            "button": {
                "color": {
                    "background": "var:preset|color|secondary-container",
                    "text": "var:preset|color|on-secondary-container"
                }
            }
        }
    }
}

Expected behavior

The editor canvas and Stylebook / Global Styles previews should generate selectors that match the actual Button block link element. Since .wp-block-button__link and .wp-element-button are on the same element, a matching selector would be closer to:

.wp-block-button.is-style-tonal .wp-block-button__link.wp-element-button

or:

.wp-block-button.is-style-tonal .wp-block-button__link,
.wp-block-button.is-style-tonal .wp-element-button

The custom style variation should look the same in front end, post editor canvas, Global Styles / Stylebook left preview, and right preview.

Actual behavior

In the editor canvas and Stylebook preview, the generated CSS includes selectors like:

:root :where(.wp-block-button.is-style-tonal .wp-block-button__link .wp-element-button,
.wp-block-button.is-style-tonal .wp-block-button__link .wp-block-button__link) {
    color: var(--wp--preset--color--on-secondary-container);
    background-color: var(--wp--preset--color--secondary-container);
}

These selectors do not match the actual markup because .wp-block-button__link and .wp-element-button are not nested. As a result, the editor shows Tonal/Elevated/Text custom variations as the default Filled button.

Observed computed values before workaround

In the post editor canvas for a core/button block with is-style-tonal:

background: rgb(103, 80, 164)  // primary, default Filled style
color: rgb(255, 255, 255)      // on-primary

Expected Tonal values:

background: rgb(232, 222, 248) // secondary-container
color: rgb(74, 68, 88)         // on-secondary-container

Reproduction notes

A local VQA page contains core/button blocks with custom variations (is-style-tonal, is-style-elevated, is-style-text).

Front end: /?page_id=13 renders correctly.
Post editor: /wp-admin/post.php?post=13&action=edit renders custom variants as Filled before applying a CSS workaround.
Global Styles / Stylebook variation preview shows the same selector mismatch.

Reference repository / commit

The issue was found while building the Axismundi block theme. The workaround commit documents the problem and enforces the variant surface with public block selectors for editor/front parity:

https://github.com/Jiwoon-Kim/axismundi/commit/8b1807e

Relevant workaround file:

https://github.com/Jiwoon-Kim/axismundi/blob/8b1807e/products/distributables/themes/axismundi/assets/styles/components.button.css

Relevant theme.json partials after workaround were reduced to registration / Global Styles discoverability only:

https://github.com/Jiwoon-Kim/axismundi/blob/8b1807e/products/distributables/themes/axismundi/styles/blocks/button-tonal.json
https://github.com/Jiwoon-Kim/axismundi/blob/8b1807e/products/distributables/themes/axismundi/styles/blocks/button-elevated.json
https://github.com/Jiwoon-Kim/axismundi/blob/8b1807e/products/distributables/themes/axismundi/styles/blocks/button-text.json

Why this matters

The new theme.json partial workflow for block style variations is otherwise very useful and works well for registration/discoverability. But for core/button, styling elements.button from a variation partial currently creates an editor/front mismatch because of the generated descendant selector. This can make a theme appear correct on the front end while authors see incorrect button styles in the editor and Stylebook previews.

Possible fix direction

When resolving elements.button for core/button style variations, the selector generator may need to account for the Button block's actual markup, where the button element is .wp-block-button__link.wp-element-button on a single node, rather than assuming .wp-block-button__link .wp-element-button as a descendant relationship.

Change History (4)

#1 @kimjiwoon
6 weeks ago

Additional note:

In the theme, I am keeping the block style variation partials in the expected/standard shape, using styles.elements.button for the core/button variants.

For example:

{
    "$schema": "https://schemas.wp.org/wp/7.0/theme.json",
    "version": 3,
    "title": "Tonal",
    "slug": "tonal",
    "blockTypes": [ "core/button" ],
    "styles": {
        "elements": {
            "button": {
                "color": {
                    "background": "var:preset|color|secondary-container",
                    "text": "var:preset|color|on-secondary-container"
                },
                ":hover": {
                    "color": {
                        "background": "color-mix(in srgb, var(--wp--preset--color--on-secondary-container) 8%, var(--wp--preset--color--secondary-container))"
                    }
                }
            }
        }
    }
}

I added a separate CSS workaround only to keep editor/front-end parity while this issue exists. The workaround targets the public Button block classes directly:

.wp-block-button.is-style-tonal .wp-block-button__link { ... }

The intent is that, once the selector generation for styles.elements.button in core/button variations is fixed, the CSS workaround can be removed and the standard theme.json partial can remain as the source of truth.

#2 follow-up: ↓ 3 @jorbin
5 weeks ago

Keywords reporter-feedback added

Issues related to the block editor should be reported in the gutenberg repo on github. Would you please report this there and then this can be closed as reported-upstream.

Additionally, it would be helpful if you could indicate if this behavior is different in 7.0 vs. previous versions.

#3 in reply to: ↑ 2 @kimjiwoon
4 weeks ago

Replying to jorbin:

Issues related to the block editor should be reported in the gutenberg repo on github. Would you please report this there and then this can be closed as reported-upstream.

Additionally, it would be helpful if you could indicate if this behavior is different in 7.0 vs. previous versions.

Thank you for the guidance.

I have reported the issue upstream in the Gutenberg repository:

https://github.com/WordPress/gutenberg/issues/79318

I confirmed the behavior in WordPress 7.0 without the Gutenberg plugin. I have not yet been able to confirm whether it also occurs in WordPress 6.9 or earlier, so I cannot currently identify it as a 7.0 regression.

I will add the version-comparison results to the upstream issue when they are available.

This ticket can be closed as reported-upstream.

#4 @wildworks
4 weeks ago

Milestone Awaiting Review
Resolution → reported-upstream
Status new → closed

Note: See TracTickets for help on using tickets.

Download in other formats:

Make WordPress Core