Widget Dashboard: host-tunable tile spacing via public custom properties - #81352
Conversation
header gap follows tile padding; defaults unchanged
04daa9c to
fdb865b
Compare
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: 0 B Total Size: 7.65 MB |
chihsuan
left a comment
There was a problem hiding this comment.
Thanks for working on this! @retrofox I tested the main dashboard, and the live tile behavior works nicely. 👍
Just one bigger-picture question:
Do we expect consumers to need different padding already? I can see the value in making it flexible, but I also wonder whether it could make dashboards feel inconsistent
between hosts. Card may eventually provide its own density prop too.
I previously created #81207 to update core default value to use 16px. I was wondering would using 16px consistently for now, give us a simpler path until we have concrete use cases for multiple densities? I don’t feel strongly either way, but I'd love to hear your thoughts.
| ``` | ||
|
|
||
| `--wp-widget-dashboard-tile-padding` controls the padding of the tile surface. `--wp-widget-dashboard-tile-header-gap` controls the space between the tile header and the body; it follows the tile padding unless set apart. Use `--wpds-*` spacing tokens as values. The floating header of full-bleed tiles and the picker previews follow the same properties. | ||
|
|
There was a problem hiding this comment.
One issue I noticed with the picker preview:
the spacing variables are expected to be set on a dashboard ancestor, but the picker is rendered through Dialog.Portal under document.body. Because CSS custom properties follow the DOM tree, the preview won’t inherit values set only on the dashboard wrapper and will fall back to the default spacing.
Maybe we want to document this or propagate the spacing values to the portal or mount it within the configured dashboard ancestor?
There was a problem hiding this comment.
Good catch; the mechanism is exactly that.
Took the documentation route: the README example now sets the properties at :root and states why, since the picker mounts in a dialog under document.body, which a wrapper's custom properties never reach.
Propagating computed values into the portal is more machinery than this bridge warrants today. If a real case arises with two dashboards at different densities on one page, that is the moment to add it.
…ard-tile-spacing # Conflicts: # packages/widget-dashboard/CHANGELOG.md
|
Thanks for your feedback, Chi. The default remains the Card default on purpose. How density should work at the system level is still an open question upstream (#74556), and the earlier implementation was dropped (#78741). These two properties are how a host of this dashboard can run that experiment: the chrome re-declares A fixed With the properties, a host that wants 16px today sets one line; if a Card density prop lands later, the properties retain their meaning and the bridge remaps to it. On consistency: values funnel through |
chihsuan
left a comment
There was a problem hiding this comment.
Makes sense, thanks for the detailed reply Damián!
Not going to block this, the package is experimental so we can always adjust the default later. LGTM! 👍
…ies (#81352) * add host-tunable tile spacing to widget chrome header gap follows tile padding; defaults unchanged * document :root placement for tile spacing vars
What?
Adds two public custom properties to the widget dashboard chrome:
--wp-widget-dashboard-tile-padding: padding of the tile surface. Defaults to the Card default (--wpds-dimension-padding-2xl).--wp-widget-dashboard-tile-header-gap: space between the tile header and the body. Follows the tile padding unless set apart; defaults to the Card default (--wpds-dimension-gap-xl).The chrome resolves them into Card's spacing properties (
--wp-ui-card-padding,--wp-ui-card-header-content-gap) at the three places that render tile chrome: the tile itself, the floating header used by full-bleed tiles, and the picker preview chrome.Part of #77616. Related: #81351 (Card spacing contract).
Why?
Dashboard hosts need denser tiles than the Card default: at small tile sizes the 24px padding takes space that self-sizing widgets need for content.
Card's spacing properties are declared on
Card.Rootitself, so hosts cannot set them through inheritance and end up with structural selectors against hashed class names.Making the header gap follow the padding avoids a double space: lowering only the padding leaves Card's derived margin positive, and the header/body separation renders as the header's block-end padding plus a content margin.
How?
Each chrome site resolves the public properties on its own element, where Card's re-declarations live. Module CSS is unlayered, so it deterministically wins over Card's
@layer wp-uideclarations.The fallback chain is repeated per site on purpose: resolving it once on a shared ancestor would recreate the inheritance trap this fixes.
The floating header for full-bleed tiles consumes the same padding property, so its toolbar stays aligned with in-card headers at any density. The preview chrome resolves the properties on its own
Card.Root, so picker previews follow the host density even though the picker dialog portals out of the dashboard subtree.Defaults are unchanged: with no host override, tiles render exactly as today.
Testing Instructions
Open the Widget Dashboard stories.
In DevTools, set
--wp-widget-dashboard-tile-padding: var(--wpds-dimension-padding-lg)on the dashboard wrapper element.Screenshots or screencast
(before/after at default and
padding-lgdensities)Follow-ups
padding-lgif agreed