ui/AlertDialog: Fix footer layout style override

[ciampo]

What?

Make AlertDialog's .footer-column compose the shared .footer and place the override in the wp-ui-compositions CSS layer.

Why?

The footer's custom column layout could randomly collapse back to a row:

• .footer-column overrides the shared .footer style, but both sat in the same CSS layer.
• With no layer difference, the winner is decided by the order the stylesheets load.
• Loading another overlay (e.g. hovering the Drawer sidebar item in Storybook) reshuffles that order, so the shared .footer wins and the override is lost.
• Reproducible in Firefox.

Putting the override in a higher layer (wp-ui-compositions) makes it win every time, regardless of load order.

How?

• The override now lives in the higher wp-ui-compositions layer, so it wins by layer precedence independent of injection order.
• .footer-column composes the shared .footer (instead of pairing the two classes via clsx in popup.tsx), so the base chrome and the override are always applied together and the relationship is self-documented in CSS.
• Added a short note in CONTRIBUTING documenting both points.

Testing Instructions

Use Firefox.

1. In Storybook, open the AlertDialog example (with footer actions).
2. Hover the Drawer item in the sidebar to trigger its styles loading.
3. The alert dialog footer must keep its column layout (actions + error message stacked) and not collapse to a row.

Screen recordings

Before:

Kapture.2026-06-04.at.16.54.09.mp4

After:

Kapture.2026-06-04.at.16.55.58.mp4

Use of AI Tools

Cursor + Opus 4.8

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>

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

[github-actions]

Size Change: 0 B

Total Size: 8.21 MB

_{compressed-size-action}

[github-actions]

Flaky tests detected in 6f2a508.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27042905548
📝 Reported issues:

• [Flaky Test] should insert hooked blocks into Synced Pattern in editor and respect changes made there #76772 in /test/e2e/specs/editor/plugins/block-hooks.spec.js

[jameskoster]

Working for me :)

[aduth]

Would another option be to move the application of the shared footer styles to be composes within the existing .footer-column styles that AlertDialog defines? I guess this is a bit concerning to me that we have to use compositions for a component's own custom classes any time that class is used in combination with some other class on an element that is meant to take priority.

[ciampo]

Would another option be to move the application of the shared footer styles to be composes within the existing .footer-column styles that AlertDialog defines? I guess this is a bit concerning to me that we have to use compositions for a component's own custom classes any time that class is used in combination with some other class on an element that is meant to take priority.

I considered that option, but I wonder if we'd still need to define the styles in the compositions layer anyway, since the AlertDialog's styles need to partially override the composed/shared styles?

In other words, I don't think that using compose will fix the bug (since it will only concatenate the class names, without moving rules to a separate layer or adding specificity).

To me, using the compositions layer here feels like the correct use of it: we're extending a base style/component and we're composing on top of it.

Is this helping with your concern, or is it still standing?

[aduth]

Ok, that suggestion may have been a misunderstanding on my part then, because this is surprising to me and I would have thought the additional styles beyond the composes would take precedent:

I don't think that using compose will fix the bug (since it will only concatenate the class names, without moving rules to a separate layer or adding specificity).

Although it could help to do both, perhaps (use composes and put in compositions layer)? That way, composes being a signal for why some styles are in compositions layer, if styles are extending (composing) some shared base styling. Even the name conveniently overlaps 😄

[ciampo]

Makes sense. Refactored to use composes instead of two separate classnames 🚀

[aduth]

Separately, do we need to audit existing usage of composes to use the compositions layer?

[ciampo]

Separately, do we need to audit existing usage of composes to use the compositions layer?

I did as part of the work in this PR, and didn't find other usages of composes that were also applying overrides on those composed styles 👌