[simison]

What?

Uses WPDS color tokens for the progress bar in @wordpress/components.

This is separate from adding new @wordpress/ui ProgressBar component, see #83781

Why?

Aligns color system with WPDS across old and new components.

ProgressBar is still actively used as it doesn't have alternative in @wordpress/ui.

How?

Uses bare WPDS tokens.

Previous implementation was using color-mix(() for $components-color-foreground and playing with opacity to always ensure contrast between bar and the track no matter what the admin accent color is (context in #55285). This time WPDS I've understood takes care of that automatically as long as we use semantically correct tokens?

Testing Instructions

Run npm run storybook:dev and see the component before/after.

Testing Instructions for Keyboard

Screenshots or screencast

Before

After

Use of AI Tools

Claude

[github-actions]

🤖 PR meta 🤖

🎉 Props

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: simison <simison@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

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

Updated as activity occurs, without notifying anyone named here. Add the props-bot label to refresh.

📦 Bundle size

Size Change: -4 B (0%)

Total Size: 8.28 MB

📦 View Changed

Filename	Size	Change
build/scripts/components/index.min.js	333 kB	-4 B (0%)

_{1277cd6 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	4310526	trunk	% Change
timeToFirstByte	57.8 ms +11.25% -1.73%	57.15 ms +13.91% -3.32%	1.14%
largestContentfulPaint	98 ms +6.12% -6.12%	98 ms +2.04% -8.16%	0%
lcpMinusTtfb	35.2 ms +23.72% -4.97%	35.6 ms +16.85% -5.62%	-1.12%
wpBeforeTemplate	28.51 ms +13.12% -1.54%	28.38 ms +20.86% -2.89%	0.46%
wpTemplate	25.2 ms +4.84% -2.86%	24.49 ms +5.14% -3.18%	2.9%
wpTotal	54.14 ms +10.69% -1.74%	53.66 ms +13.25% -3.99%	0.89%
wpMemoryUsage	7.63 MB +0% -0%	7.60 MB +0% -0%	0.46%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	4310526	trunk	% Change
timeToFirstByte	43 ms +7.33% -1.98%	43.15 ms +9.27% -1.97%	-0.35%
largestContentfulPaint	92 ms +2.17% -0%	92 ms +4.35% -4.35%	0%
lcpMinusTtfb	48.3 ms +1.97% -2.8%	48.7 ms +1.64% -5.65%	-0.82%
wpBeforeTemplate	26.35 ms +3.3% -2.54%	26.63 ms +5.82% -2.82%	-1.05%
wpTemplate	13.58 ms +4.71% -0.52%	13.68 ms +4.53% -1.46%	-0.73%
wpTotal	40.18 ms +7.44% -2.12%	40.49 ms +8.4% -2.47%	-0.77%
wpMemoryUsage	6.12 MB +0% -0%	6.08 MB +0% -0%	0.59%
wpDbQueries	10 +0% -0%	10 +0% -0%	0%

media-processing

Metric	4310526	trunk	% Change
mediaProcessingJpeg	402.27 ms +0.44% -0.49%	401.89 ms +0.53% -0.47%	0.09%
mediaProcessingAvif	6056.99 ms +0.33% -0.07%	6047.35 ms +0.44% -0.13%	0.16%
mediaProcessingJpegToAvif	4186.67 ms +0.17% -0.42%	4171.63 ms +0.17% -0.23%	0.36%

media-upload

Metric	4310526	trunk	% Change
jpegUploadProcessing	1434.63 ms +36.44% -1.87%	1412.24 ms +0.86% -0.34%	1.59%
pngUploadProcessing	174.64 ms +8.06% -4.4%	176.83 ms +26.96% -1.66%	-1.24%
largeJpegUploadProcessing	1412.9 ms +0.6% -0.75%	1408.4 ms +0.5% -0.84%	0.32%
multipleImageUploadProcessing	1604.8 ms +30.04% -2.34%	2062.23 ms +0.28% -24.18%	-22.18%

post-editor

Metric	4310526	trunk	% Change
serverResponse	336.3 ms +5.4% -6.53%	339.89 ms +4.02% -4.06%	-1.06%
firstPaint	150.6 ms +20.36% -8.11%	154.25 ms +27.36% -9.45%	-2.37%
domContentLoaded	830.52 ms +1.19% -2.05%	835.17 ms +1.15% -3.36%	-0.56%
loaded	831.38 ms +1.21% -2.05%	836.18 ms +1.14% -3.38%	-0.57%
firstContentfulPaint	353.51 ms +3.09% -7.33%	358.85 ms +1.29% -6.89%	-1.49%
firstBlock	2360.12 ms +0.42% -0.62%	2405.16 ms +0.33% -0.91%	-1.87%
type	15.8 ms +2.66% -5%	15.14 ms +5.81% -1.65%	4.36%
typeWithoutInspector	14.9 ms +4.56% -1.14%	15.25 ms +2.03% -3.87%	-2.3%
typeWithTopToolbar	19.76 ms +6.63% -1.67%	19.63 ms +4.58% -4.33%	0.66%
typeContainer	7.87 ms +4.7% -9.66%	7.52 ms +6.12% -7.05%	4.65%
focus	57.57 ms +11.78% -1.51%	56.16 ms +8.44% -4.47%	2.51%
firstFocus	158.96 ms +0% -0%	156.34 ms +0% -0%	1.68%
selectAll	355.64 ms +0.05% -3.92%	340.44 ms +8.28% -5.58%	4.46%
listViewOpen	47.13 ms +8.74% -12.92%	51.43 ms +2.55% -10.44%	-8.36%
inserterOpen	19.25 ms +15.69% -5.56%	18.79 ms +28.95% -5%	2.45%
inserterHover	1.69 ms +17.16% -11.83%	1.65 ms +10.3% -14.55%	2.42%
inserterSearch	7.37 ms +4.34% -6.92%	6.96 ms +12.93% -5.75%	5.89%
loadPatterns	517.37 ms +2.06% -4.77%	516.48 ms +3.01% -1.76%	0.17%
wpTotal	327.83 ms +5.24% -6.79%	331.63 ms +3.88% -4.25%	-1.15%
wpMemoryUsage	13.18 MB +0% -0%	13.15 MB +0% -0%	0.28%
wpDbQueries	54 +0% -0%	54 +0% -0%	0%

site-editor

Metric	4310526	trunk	% Change
serverResponse	309.99 ms +4.75% -2.74%	369.18 ms +2.79% -2.77%	-16.03%
firstPaint	178.21 ms +12.95% -9.61%	233.19 ms +21.52% -5.76%	-23.58%
domContentLoaded	904.88 ms +0.85% -0.99%	1117.17 ms +1.1% -5.02%	-19%
loaded	906.01 ms +0.83% -0.99%	1118.29 ms +1.12% -4.95%	-18.98%
firstContentfulPaint	372.1 ms +1.41% -1.96%	456.05 ms +2.94% -1.56%	-18.41%
firstBlock	3222.01 ms +1.6% -0.58%	4041.23 ms +1.6% -1.15%	-20.27%
type	16.15 ms +7.06% -4.4%	24 ms +9.83% -15.25%	-32.71%
navigate	97.43 ms +23.88% -8.74%	123.98 ms +10.91% -18.67%	-21.41%
loadPatterns	1072.47 ms +0.57% -1.98%	1492.86 ms +9.83% -7.31%	-28.16%
loadPages	1064.75 ms +0.45% -1.63%	1134.03 ms +2.36% -3.34%	-6.11%
wpTotal	301.5 ms +4.84% -2.72%	359.65 ms +2.77% -2.72%	-16.17%
wpMemoryUsage	12.14 MB +0% -0%	12.13 MB +0% -0%	0.14%
wpDbQueries	43.5 +1.15% -1.15%	43.5 +1.15% -1.15%	0%

_{1277cd6 Run}

🏁 Flaky tests

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.

can use focal point picker to set the focal point of the cover image in /test/e2e/specs/editor/blocks/cover.spec.js, passed after 1 failed attempt.

Error: expect(locator).toHaveValue(expected) failed

Locator:  getByRole('group', { name: 'Focal point' }).getByRole('spinbutton', { name: 'Focal point left position' })
Expected: "20"
Received: "50"
Timeout:  5000ms

Call log:
  - Expect "toHaveValue" getByRole('group', { name: 'Focal point' }).getByRole('spinbutton', { name: 'Focal point left position' }) with timeout 5000ms
  - waiting for getByRole('group', { name: 'Focal point' }).getByRole('spinbutton', { name: 'Focal point left position' })
    14 × locator resolved to <input min="0" step="1" max="100" value="50" type="number" autocomplete="off" inputmode="numeric" id="inspector-input-control-0" aria-label="Focal point left position" class="components-input-control__input ba-d-f-ee-bbccdd-7njioi em5sgkm3"/>
       - unexpected value "50"

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/blocks/cover.spec.js:427:34

_{1277cd6 Run}

[jameskoster]

Maybe we should use --wpds-color-background-thumb- and --wpds-color-background-track- for this?

[ciampo]

Agree with Jay re. using those WPDS tokens. In case they don't fit, we can consider tweaking them (or creating variants as needed)

Separately, let's make sure that the custom override in CanvasLoader continues to work.

We can consider introducing a less hacky way to override the bar in the @wordpress/ui version that I'm about to open a PR about

[simison]

@ciampo @jameskoster updated — is it ok to do a breaking change in a way that consumers now cannot continue to use --wp-components-color-foreground to override the progress bar color?

Alternatively, we leave this as-is, deprecate and continue with @wordpress/ui version instead

[simison]

Plus the thumb token changes from neutral-by-default to brand accent — which might be ok but wanted to highlight that it's more visible change:

instead of:

Now it's:

[ciampo]

Some thoughts:

• thumb should stay neutral, meaning that we need to rework tokens to expose both neutral and brand track colors, and continue to use neutral in this component;
• overriding --wp-components-color-foreground is a hack and therefore I don't think we should mark this as a breaking change.

In any case, the new version of the component in @wordpress/ui will explore those functionality from the start with dedicated APIs

[simison]

overriding --wp-components-color-foreground is a hack and therefore I don't think we should mark this as a breaking change.

Makes sense; I just see it in practice in the wild so much that it will, in practice, affect consumer UIs between WP versions, but it's not super significant.

[mirka]

Unfortunately it seems that useStyle( 'color.text' ) can return any valid CSS color such as hsl(...), and ThemeProvider.color.primary will reject HSL and throw.

I wonder how common a theme use case this is 🤔 If it is, maybe we would need to support a way to resolve the value at runtime ("inject at the ThemeProvider node and read" technique). cc @ciampo

[simison]

In this case, it's probably best to merge the UI version first, use it here with its color prop and then we don't need ThemeProvider

[ciampo]

Agreed, came to say the same. The ui version should natively allow custom thumb colors without the need for ThemeProvider

[mirka]

So I guess spinners and progress bars are a special case where we need to allow flexible colors, unbounded by the theming system. They're presentational, noninteractive, and need to blend into different surroundings. (Just making the criteria clear so we don't end up adding color props to everything.)

[jsnajdr]

One way to work around is to make the browser parse the color and convert it to RGB:

const textColor = useStyle( 'text.color' );
const el = document.createElement( 'div' );
el.style.color = textColor;
const rgbColor = el.style.color;

But this works only for HSL and similar spaces that have the same gamut as RGB. OKLCH and wide-gamut spaces won't be converted.

The text.color value can be completely arbitrary, it's user input that comes from global styles or from theme.json.

[ciampo]

So I guess spinners and progress bars are a special case where we need to allow flexible colors, unbounded by the theming system.

I think so, or at least that's an escape hatch that only applies to those elements

The canonical solution would be to go through ThemeProvider, but I'm not sure we should add more complexity there to parse any color syntax 🤔 At most, it would be on the canvas loader to resolve the value to a supported theme provider seed color?

[ciampo]

currentColor support will be tricky though, since it would need to be computed and converted to a fixed CSS color so that the color ramp computation can take place. And we'd need a way to observe it since it can implicitly change as a result of "external" CSS changes.

All in all, I continue to think that the level of complexity necessary to support those use cases may not be worth it 🤔

[simison]

Agreed not adding more complexity now and that meter/progress/spinner are a bit special.

Most of the custom color usage I can think of is more "meter" than "progress" usage (red/yellow/green) but progress could also turn yellow or red when offline/paused, or green after success or finishing last step of onboarding. Or e.g. a countdown bar which turns more red as it progresses and time runs out.

It could make sense to have an intent prop, especially for the meter, so that folks don't need to provide colours manually for common use cases.

Worth likely including some examples in the Storybook.

[simison]

I cherry-picked neutral thumb color commit from #65528 and used --wpds-color-background-thumb-neutral here (hence don't mind the changelog validator for now). Updated the PR screenshot.

I think it's best to merge the UI version first, use it in the canvas loader, then rebase this.

[ciampo]

Update: #83860 is about to get merged, we can resume work on this PR :)

[simison]

Rebased after #83781 and #83860

[ciampo]

LGTM 🚀