Post Stats: draw the chart chrome in tokens instead of hardcoded black - #793
Merged
epeicher merged 3 commits intoSep 11, 2026
Merged
Conversation
The grid lines, y-axis ticks and month labels were painted with literal black — rgba(0,0,0,0.07) / 0.35 / 0.5. `.os-widgets__card` is a fixed dark glass in every desktop theme, so composited over the wallpaper they measured 1.01:1 and 1.02:1: invisible. The bars survived only because they use the explicit COLORS map, and the widget's own DOM text stayed legible because its stylesheet already reads the tokens. The canvas now reads the same two custom properties that stylesheet uses — `--os-ui-color-border` for the rules, `--os-ui-color-text-subtle` for both sets of labels. The ad-hoc alphas go with the black: the tokens already encode the intended hierarchy, and a canvas cannot cheaply apply an alpha to an arbitrary colour string. The fallbacks are the dark-glass values from variables.css, not the old black. A fallback is what ships when the token does not resolve, so a black one would restore the bug in exactly the case it exists to cover. Fixes WordPress#762
Collaborator
|
Thanks for your contribution @juanlentino! Two small things:
|
Satisfies @wordpress/no-unused-vars-before-return: RULE and LABEL were assigned before the chartW/chartH guard could return without using them. Behaviour unchanged.
epeicher
approved these changes
Sep 11, 2026
epeicher
left a comment
epeicher
left a comment
Collaborator
There was a problem hiding this comment.
Thanks @juanlentino! It looks much better now. Changes also LGTM!
| Before | After |
|---|---|
 |
 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #762.
The change
Three canvas paints in
src/plugins/post-stats-widget/index.tswere literal black:rgba(0,0,0,0.07)--os-ui-color-borderrgba(0,0,0,0.35)--os-ui-color-text-subtlergba(0,0,0,0.5)--os-ui-color-text-subtleThese are the same two custom properties the widget's own stylesheet already uses for its DOM text — which is precisely why the title, the
39 posts in 6 mometadata and the legend were legible while everything on the canvas was not. The bars survived because they use the explicitCOLORSmap.Two decisions worth flagging
The ad-hoc alphas go with the black.
0.07 / 0.35 / 0.5were compensating for black ink on a light assumption; the tokens already encode the rule-vs-label hierarchy, and a canvas cannot cheaply apply an alpha to an arbitrary colour string without parsing it. If you'd rather keep a weight difference between the ticks and the month labels,globalAlphaaround the tick pass is the clean way and I'm happy to take direction on it.The fallbacks are deliberately not black.
getPropertyValue()returns''when a token has not resolved, so the fallback is what ships in exactly the case the token exists to cover. Falling back to black would restore the bug there. Both fallbacks are the dark-glass values fromvariables.css.Tests
Two cases added to
tests/vitest/widget-card-token-contract.test.ts, which already exists for this class of bug. One asserts the source carries no literal black and reads both tokens; the other asserts the fallbacks are legible on the glass — without that, a future edit could satisfy the first pin and still ship black as the fallback.A canvas cannot be asserted in jsdom without a 2D context, so these are source-level pins rather than rendered-pixel ones. That is a real limitation of the check and worth knowing when reading it.
Verification caveat, same as my other PRs: I could not run your vitest suite —
devEnginespins Node to>=24 <25and this machine is on v26, so npm refuses before install. I ran each pin's logic in plain node against the real file in both directions: it passes on the patched source and trips on the pre-patch source, so the guard is failable rather than vacuous. The vitest harness itself is unexercised.