A spinner sized with 1em can visibly wobble while rotating in Safari/WebKit. The issue appears to come from subpixel rendering: the rotation is stable when the computed width and height resolve to even pixel values, but font-relative sizes often land between pixels. Common compositing tricks such as will-change: transform, translateZ(0), and backface-visibility: hidden do not seem to help because this is not primarily a compositing problem. The fix is to snap the dimensions to the nearest 2px while keeping them responsive to the surrounding font size: .spinner { height: round(1em, 2px); width: round(1em, 2px); } How reliable is this with accessibility font-size overrides, and are there compatibility concerns?
3 Answers
The solution also appears to hold up when Safari has a larger minimum font size enabled, which is important for accessibility. Support can vary by platform and version, though; it reportedly is no longer needed on newer macOS releases while remaining useful on newer iOS releases.
This is a useful use case for round(). Even if the default 1em happens to resolve to an even number, browser settings or accessibility extensions can increase the font size and produce a value that renders poorly. Snapping the result lets the spinner remain font-relative without depending on the user’s exact font metrics.
Another approach is to give the rotating element fixed pixel dimensions and scale a wrapper with transform. That keeps the rotating geometry stable and avoids relying on font metrics, but round(1em, 2px) is a cleaner option when you want the spinner itself to follow the surrounding text size.
The main caveat is browser support: the length-based round() form is newer, so older Safari versions may ignore it. A fallback or fixed-size approach may be worthwhile if those browsers matter.
Exactly. It keeps the component adaptable while avoiding subpixel dimensions caused by unusual or overridden font sizes.