Widget Dashboard: preserve widget chrome flex layout

[dognose24]

Why

On a production WordPress site, the hosting platform concatenates a legacy admin-wide stylesheet into every wp-admin page (it's platform-level CSS, not something a plugin or theme on the site enqueues), and it ships an unscoped HTML5 display reset — article, aside, …, section, summary { display: block; } — unlayered. The Card styles live inside @layer wp-ui.components, and unlayered rules beat layered ones regardless of specificity, so the widget chrome's <section> computed display: block. The chrome's content area then lost its flex height constraint (flex: 1 / min-height: 0 are inert without a flex parent, while its height: 100% still applies in block flow), quietly overflowed the tile, and the tile's overflow: clip cut off the bottom of every widget — e.g. a chart's x-axis labels.

Any host page can carry such CSS (wp-admin loads arbitrary plugin, theme, and platform styles), so the dashboard should not depend on a layered rule for its structural layout.

What

• Restate the widget chrome's structural flex-column layout on its own module class (widget-chrome.module.css). No Card.Root styles are modified.
• The module CSS ships unlayered, so within the unlayered tier normal specificity applies and the class rule beats element-selector resets — no !important needed.
• The chrome's children already rely on this invariant (flex: 1 + min-height: 0 on the content assume a column flex parent), so in a clean host this is a visual no-op; the change only makes the existing contract self-contained.
• Document the hardening in the package changelog.

Test plan

1. Open any Widget Dashboard story with a rendered widget tile.
2. In DevTools, inject an unlayered reset: document.head.insertAdjacentHTML('beforeend', '<style>section{display:block}</style>').
3. Before this patch: the chrome <section> computes display: block and the widget body overflows the tile (bottom clipped, e.g. chart x-axis labels).
4. With this patch: computed styles remain display: flex; flex-direction: column and the layout is unaffected.
5. Without the injected reset, confirm tiles render identically to trunk (visual no-op).

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @dognose24! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[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: dognose24 <dognose24@git.wordpress.org>
Co-authored-by: retrofox <retrofox@git.wordpress.org>

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

[retrofox]

Thanks, Dognose, for this PR. I'm not entirely sure what the motivation for this PR is. Could you provide clearer testing instructions? It touches the regular Card.Root component styles.

[dognose24]

@retrofox Thanks for taking a look, and fair — the description buried the motivation. Context:

We hit this in production on a WordPress site: its wp-admin loads a legacy admin-wide stylesheet that ships an unscoped HTML5 display reset — article, aside, …, section, summary { display: block; } — unlayered. The Card styles live inside @layer wp-ui.components, and unlayered rules win over layered ones regardless of specificity, so the widget chrome's <section> fell back to display: block. The content area then lost its flex height constraint, overflowed the tile, and the tile's overflow: clip cut off the bottom of every widget — e.g. a chart's x-axis labels.

Here's the Styles panel on the affected site — the Card's display: flex struck through inside @layer wp-ui.components while the unlayered reset wins (note the chrome's own module rules carry no layer, and their border-radius even beats the Card's — which is exactly why this fix works):

To be clear, the PR doesn't touch Card.Root's styles — it only restates the chrome's structural layout on its own module class (widget-chrome.module.css). The module CSS ships unlayered, so within the unlayered tier normal specificity applies and the class rule beats the element reset — confirmed empirically by adding display: flex to the chrome's module rule in DevTools on the affected site, which restores the layout. The chrome's children already rely on this invariant (flex: 1 + min-height: 0 on the content only make sense with a column flex parent), so in a clean host this is a visual no-op.

Clearer test plan:

1. Open any Widget Dashboard story with a rendered tile.
2. In DevTools, inject an unlayered reset: document.head.insertAdjacentHTML('beforeend', '<style>section{display:block}</style>').
3. Before this patch: the chrome section computes display: block and the widget body overflows the tile (bottom clipped). With this patch: computed styles stay display: flex; flex-direction: column and the layout is unaffected.

Could you also add the [Type] Enhancement label? I don't have permission. Thanks!

[retrofox]

Thanks for the follow-up, @dognose24.

You're right that the patch leaves Card.Root untouched, and the cascade reasoning checks out: the Card styles are layered, the dashboard's module CSS is not, so the module class wins over the host reset. .tile in widgets.module.css already restates the Card's border-radius the same way.

One change before merge. WidgetPreviewChrome renders the same Card.Root render={ <section /> } around the same WidgetFrame, so the picker previews break identically. Could you restate display: flex; flex-direction: column on .card in widget-preview-chrome.module.css too?

Out of curiosity, which stylesheet ships the reset? No core wp-admin stylesheet carries one, so it looks like a plugin or theme. Worth naming it in the description.

[dognose24]

Done — .card in widget-preview-chrome.module.css now restates display: flex; flex-direction: column as well, and the changelog entry covers both chromes.

On the reset source: it's not core, and not a plugin or theme on the site either — the site's hosting platform concatenates a legacy admin-wide stylesheet into wp-admin, and its opening rules include the classic HTML5-Boilerplate-era article, aside, … section, summary { display: block; } reset, unscoped and unlayered. I've updated the description accordingly. Being platform-level CSS outside any plugin author's control, it reinforces keeping the chrome's structural layout self-contained.

Mind adding a [Type] Bug label when you get a chance? The two failing checks are just the label requirement.

[retrofox]

Thanks, Dognose. LGTM 👍