Position block support: derive container class from styles so identical rules are deduplicated

[mukeshpanchal27]

What problem does this address?

gutenberg_render_position_support() builds its container class from a per-request counter:

<?php
$class_name = wp_unique_id( 'wp-container-' );

Every block instance with position support therefore gets its own class and its own rule in the block-supports style engine store, even when the resulting CSS is byte-for-byte identical.

The other block supports that emit a scoped rule derive the class from the style inputs, so identical styles collapse into one rule:

gutenberg/lib/block-supports/custom-css.php

Line 46 in bbbc103

$class_name = wp_unique_id_from_values( $parsed_block, 'wp-custom-css-' );

Impact

With 200 Group blocks that all use position: sticky; top: 0px:

	Rules in store	Generated CSS
trunk	200	22,092 bytes
patched	1	116 bytes

This CSS is inlined into every front-end response, so the duplication adds page weight on every request, on top of the render cost.

WordPree core trac ticket: https://core.trac.wordpress.org/ticket/66200

[singhakanshu00]

Some history that might help frame the fix.

Position support was split out of layout support in #46142 (Jan 2023) and inherited layout's class-naming approach of the time, wp_unique_id( 'wp-container-' ). Layout has moved on twice since:

• Make layout support compatible with enhanced pagination #55416 (Oct 2023) replaced the shared counter with gutenberg_incremental_id_per_prefix(), because one global counter meant rendering a different number of blocks shifted the class names of every block after them. The stated motivation was the Query block's enhanced pagination, which needs class names to stay stable across requests.
• Layout Support: Replace incremental IDs with hashes #68210 (Mar 2025) replaced the per-prefix counter with a hash of the layout inputs.

Position stayed on the original approach through both. So this looks less like a deliberate difference between the two supports and more like the one caller that wasn't updated when layout moved on.

That history also points at a possible second symptom beyond the duplicated CSS in the report: a per-request counter is render-order dependent, so a block's position class isn't stable across requests - which is exactly what #55416 describes for layout. I haven't tested this against enhanced pagination, so I'd treat it as worth checking rather than confirmed. If it does reproduce, it's a correctness bug rather than a page-weight one, and the same fix covers both.

On the fix itself, one detail where position probably shouldn't copy layout verbatim. Layout puts the block name in the prefix:

'wp-container-' . sanitize_title( $block['blockName'] ) . '-is-layout-'

so two blocks with identical layout config still get separate classes. Position has no equivalent reason for that - everything gutenberg_get_position_support_styles() emits is position, z-index and the four offsets, none of which depend on the block type. So two groups with sticky position with the same offsets want byte-identical CSS and can share a class, so including the block name would leave most of the available dedupe on the table.

Concretely, replacing the wp_unique_id() call would look roughly like this. $responsive_media_queries is already in scope by that point, so it slots in where the current line is:

$hash_input = array( $style_attribute['position'] ?? null );

foreach ( $responsive_media_queries as $breakpoint => $media_query ) {
	$hash_input[] = $style_attribute[ $breakpoint ]['position'] ?? null;
}

$class_name = gutenberg_unique_id_from_values( $hash_input, 'wp-container-position-' );

Two things that matter in that input:

• It has to cover the base style.position and every viewport state override, hashed together rather than separately. One class covers all of a block's position rules - the same selector is reused for each breakpoint, only rules_group varies - so the class has to identify the whole bundle. Two blocks can share a base position and differ only at a breakpoint, and hashing the base alone would give them one class and one merged rule, silently applying the wrong breakpoint behaviour to one of them. The ?? null entries are what keeps "no override at this breakpoint" distinguishable from an override.
• $allowed_position_types doesn't need to be in it. It comes from gutenberg_get_global_settings() with no block context, so it's identical for every block in the request, and two blocks with matching position attributes always produce matching CSS. Including it is harmless but not load-bearing.

Worth noting the dedupe itself needs no new code. WP_Style_Engine_CSS_Rules_Store::add_rule() keys on the selector and returns the existing rule when one is present, merging declarations into it. Matching class names are enough for the collapse to happen on its own - the current counter is the only thing preventing it.

This does change the emitted class names, but the current ones are a per-request counter, so they already differ between requests for the same block and nothing could reasonably have been depending on them.

Happy to open a PR for this if nobody's already on it.