Block Supports: Reuse block style variation instance for consecutive blocks

[sanketio]

wp_render_block_style_variation_support_styles() mints a fresh instance class for every block that uses a block style variation, and enqueues a complete copy of that variation's CSS for each one. The generated CSS is identical apart from the instance number, so a page with N blocks sharing a variation ships N copies of the same rules.

With Twenty Twenty-Five and repeated Outline buttons:

Outline buttons on page	Inline CSS	Rules emitted	Distinct rules
3	1,663 bytes	6	2
20	10,782 bytes	40	2

Growth is linear and unbounded. There is no rendering difference — computed border colour, width, background and padding are identical regardless of how many copies are emitted — so this is purely wasted payload.

This reuses the previous instance only when the immediately preceding variation instance is the same one. Nothing else was emitted in between, so re-emitting would be a no-op in cascade terms and the class can safely be shared. Anything interleaved forces a fresh instance, so current ordering is preserved exactly.

Why not cache by variation slug for the whole request

That would reintroduce #61877, which is why 0a9dcb4 replaced md5( serialize( $block ) ) with wp_unique_id() in the first place.

Variation selectors are wrapped in :where(), so every variation rule has the same specificity and source order alone decides which one wins. The per-instance class is what places a nested variation's styles after its ancestor's. Tested with two core/group variations styling paragraphs differently — demo-a red, demo-b blue — laid out as a standalone A followed by a B containing an A:

Implementation	Emission order	Inner paragraph
trunk today	demo-a--2 -> demo-b--3 -> demo-a--4	red (correct)
cache by slug	demo-a--2 -> demo-b--3	blue (wrong)

Limiting reuse to the immediately preceding instance keeps that safe: a nested block always has its ancestor's variation emitted in between, so it never shares a class with an earlier one.

test_block_style_variation_does_not_reuse_instance_across_a_different_variation guards this and is annotated with both tickets.

Results

Case	Before	After
3 outline buttons	1,663 bytes / 6 rules	593 bytes / 2 rules
20 outline buttons	10,782 bytes / 40 rules	593 bytes / 2 rules
Nested section styles	6,130 bytes / 58 rules	unchanged, byte for byte
Nested demo-a / demo-b	inner paragraph red	still red

Known limitation: an alternating A B A B sequence still emits a copy per instance. Fully deduplicating would require collecting variations during render and emitting them ordered by nesting depth rather than document order, which is a considerably larger change.

Testing

npm run test:php -- --filter Tests_Block_Supports_BlockStyleVariations

test_block_style_variation_reuses_instance_for_consecutive_blocks fails on trunk without this change.

Note when verifying manually: Twenty Twenty-Five's own section styles set descendant colours with currentColor, so nesting section-1 inside section-2 produces byte-identical descendant rules and shows no visible change even when ordering is broken. A cascade regression only surfaces with variations that set absolute values.

The same change is proposed for the Gutenberg plugin in WordPress/gutenberg#81609, for WordPress/gutenberg#81583.

Trac ticket: https://core.trac.wordpress.org/ticket/65876

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Investigating the cause, drafting the implementation and the unit tests. All changes, measurements and test results were reviewed and verified by me.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props sanketparmar.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.