Post Terms Block: Link Color being overridden by core link styles

[bacoords]

Description

Apply a link color to the Post terms block- it'll work in the editor but not on the frontend. The core link style is applied directly to the <a> element and overrides it:

a:where(:not(.wp-element-button)) { ... }

Step-by-step reproduction instructions

1. Download the latest Gutenberg (17.8.0)
2. Add a Post Terms block to your Query Loop (for example, the categories block variation)
3. Apply a text Link color to the post terms block that is different than the site's existing link color
4. View on the frontend

Screenshots, screen recording, code snippet

Screen.Recording.2024-03-01.at.6.37.37.AM.mov

Environment info

• WordPress 6.4 AND Gutenberg 17.8.0
• Replicated in TT4 theme and other themes (noticed originally in Wabi)

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[t-hamano]

I looked into this issue and found that it was caused by the render_block_data hook added in #59057. The problem will probably occur if you apply an element-targeted style to all nested blocks.

The cause is that the hash value included in the CSS selector targeting the element and the hash value included in the CSS class name of the element do not match. The cause is probably the same as the one investigated in this comment.

The detailed reasons are as follows:

• First, a CSS stylesheet is generated here via the pre_render_block hook. The CSS selector uses an md5 hash value generated based on the $block array.
• The render_block_data hook added by #59057 is executed. This hook adds a new key (parentLayout) to the nested block.
• The gutenberg_render_elements_support() function is then executed via the render_block_data hook.
• An md5 hash value is generated based on the $block array here, and the CSS class is applied to the target element. However, at this point we have added the parentLayout key to the $block array, so it will generate a different hash value.
• As a result, the style will not be applied because the generated CSS style sheet and the class name of the element do not match.

In other words, in order for CSS targeting an element to be applied correctly, it is assumed that the $block array that are the arguments of the pre_render_block hook and the render_block_data hook match exactly. By rewriting the $block array with either hook, you can easily break styles that target elements.

I'm wondering if there is a more robust approach, but I haven't come up with any ideas yet 😅

[t-hamano]

I think the root cause is the same as #59462, so let's close this issue.

[aaronrobertshaw]

This issue has been fixed via #59533.