Add stroke-width style based on --track-width to <wa-spinner>

[curtiskeller]

Update spinner to respect track width property. Issue #1317

[vercel]

@curtiskeller is attempting to deploy a commit to the Font Awesome Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
webawesome	Ready	Preview	Aug 19, 2025 7:39pm

[claviska]

We may want to use em units instead of pixels, as this changes makes the spinner look thinner at various sizes.

Current

Proposed

@lindsaym-fa what do you think?

Maintainer notes:

• Needs changelog

[lindsaym-fa]

I fell down a bit of a rabbit hole with this one, but if we'd like to keep the scope of this issue contained, I'd recommend setting --track-width: 4px by default.

It seems because we're setting a viewBox and cx, cy, and r attributes that are relative to that viewBox on the internal <svg> elements, then scaling the viewBox based on the font size, the pixel values within consequently scale proportional to the font size too. Using em values has the effect of exaggerating the scaling since the stroke essentially scales twice — once because of the applied em value, and again because of the scaled viewBox.

And there's the 🐰🕳️: 4px =/= 4px. That's seems...unexpected.

For example, here's what --track-width: 4px looks like in the doc's Size example:

Screen.Recording.2025-08-20.at.11.52.07.AM.mov

None of those strokes are exactly 4px. The largest example, which uses font-size: 3rem, is the closest. In any case, we wouldn't expect 4px to scale with the font size.

Here's what --track-width: 0.25em looks like for comparison:

Screen.Recording.2025-08-20.at.11.51.40.AM.mov

We'd expect the stroke width of the first to render as 4px, the second as 8px, and the third as 12px. Instead, the first looks closer to ~1px, the second ~5px, and the third ~10px. And, notably, the svg starts to be clipped at the largest size.

There's more to resolve here to ensure that the applied --track-width is accurate. @claviska, do we want to add --track-width in this PR (by the way, thank you for catching this @curtiskeller!) and investigate the overall scale/sizing issue separately? Or should we handle them all together?

[claviska]

Great analysis. I would vote for handling them all together unless there’s a good reason not to.

[curtiskeller]

No problem! Just to confirm, you would like me to change the --track-width default value to 4px, then leave the rest of the changes as-is to handle track and indicator at the same time? @lindsaym-fa

[lindsaym-fa]

No further action required from you right now, @curtiskeller! I'll start digging into how we can fix the sizing for <wa-spinner> so that the set --track-width is actually accurate, and we'll merge your commit along with that fix when it's ready. I suggested 4px because it works well for <wa-spinner> in its current state, but once we fix the underlying sizing issue, a different value might be more appropriate. I'll keep you posted!