20 CSS Loading Buttons

The label is the problem: "Save" is narrower than "Saving…", so swapping the text makes the button grow and shove whatever sits beside it. Three fixes work, and they suit different cases. Stack both labels in the same grid cell with grid-area: 1 / 1 and crossfade opacity between them — the button sizes to the wider of the two and never moves. Or set a min-inline-size in ch units, sized to the longest label the button will ever hold, which is simplest when the states are known up front. Or reserve the spinner's box with visibility: hidden rather than display: none, so the space exists before the spinner appears. What does not work is swapping textContent and hoping, which is the default approach and the reason so many production buttons visibly jump. The shift is not only ugly — it is a Cumulative Layout Shift event, and a button near other controls can push a mis-click onto the wrong target.

Set the disabled property on the element itself, not a class that only changes appearance. A class with pointer-events: none stops the mouse but not the keyboard — the button still activates on Enter or Space, so a determined double-tap still fires twice. disabled makes the browser refuse activation from every input method, which is the whole point. There is a real tradeoff, though: a disabled element is removed from the tab order and silently drops focus, so a keyboard user who just pressed the button is dumped back at the top of the document with no idea what happened. When focus must persist, use aria-disabled="true" plus a guard clause that returns early from the handler — the button stays focusable and announces as unavailable, and your own code blocks the second call. Belt and braces is to also guard on the state itself: if data-state is already pending, return immediately.

A spinner is a visual-only signal — it fires no accessibility event, so a screen reader user gets silence while the page waits. Three things fix that. Put aria-busy="true" on the button while the request is in flight and clear it on resolution, which is the standard way to say "this control is working". Announce the outcome through a live region: an element with aria-live="polite" that you write "Changes saved" into on success. Use role="alert" for the failure path instead, because a failed save is urgent and polite announcements can be queued behind other speech. Beyond that, never rely on colour alone for the error state — red plus a label, or red plus an icon. And if the button shows determinate progress, it needs role="progressbar" with aria-valuenow, aria-valuemin and aria-valuemax kept in sync, or the percentage is invisible to assistive technology.

Because the response came back faster than a human can register the spinner. A request that resolves in 90 ms makes the spinner appear and vanish inside a couple of frames, which reads as a glitch rather than as feedback — users report it as "the button flickered", not "that was fast". The fix is two thresholds. Do not show the pending state at all for the first ~150 ms: if the work finishes inside that window, the button simply goes straight to its result and the interaction feels instant. If the spinner does appear, hold it for a floor of ~400 ms even when the response arrives sooner, so it is on screen long enough to read. Both numbers are judgement calls rather than standards, but the shape is well established and it is what makes fast interfaces feel calm instead of twitchy. The same reasoning applies to skeletons and progress bars — anything that appears and disappears too quickly costs more than it communicates.

Optimistic UI shows the success state immediately, before the server has confirmed anything, then reconciles when the real answer arrives. A settings toggle that reads "Saved" the instant you flip it feels dramatically faster than one that spins for 400 ms first, and in the overwhelming majority of cases the write does succeed. The honest tradeoff is that it occasionally lies. If the request fails you must roll the interface back visibly and say so — a silent revert is worse than a spinner, because the user has already moved on believing the change stuck. That makes it a good fit for low-stakes, easily-reversed writes: preferences, toggles, likes, draft edits. It is a bad fit for anything the user cannot undo or would be harmed by mis-reporting — payments, deletions, submissions with legal weight. For those, make the wait explicit and let the button stay pending until the server actually answers.

An undo window is usually better, and it is what most modern products have moved to. A confirmation dialog interrupts every deletion to guard against the rare mistake, which means the frequent correct action pays the cost of the infrequent wrong one — and people learn to dismiss the dialog reflexively, so it stops protecting anything. An undo window inverts that: the delete happens immediately, the row disappears, and a timed affordance offers to put it back. The common case is fast, and the mistake is still recoverable. Two details make it work. The countdown must be visible so the user knows the window is finite, and the undo control needs a real focus path, not just a mouse target. Keep dialogs for actions that genuinely cannot be undone — permanently destroying data, spending money, anything with a legal or financial consequence — where the interruption is doing real work.

Drive a single custom property from your progress events and let CSS do the rest: button.style.setProperty('--progress', pct), with the background reading that value through a gradient stop or a scaled pseudo-element. Register the property with @property and a <percentage> syntax so it can transition smoothly between updates instead of stepping between them — an unregistered custom property is just a string to the engine and will not interpolate. If you show a number alongside the bar, set font-variant-numeric: tabular-nums so the digits stay the same width and the label does not jitter on every update. One honesty point worth making: only show a percentage when you actually know the total. If the response is streamed or the size is unknown, a percentage is invented and users notice when it stalls at 90% — an indeterminate spinner is the more truthful control.

The CSS ports unchanged — every .lb-NN selector and custom property is framework-agnostic, and the five pure-CSS demos need no JavaScript anywhere. The state machine is where framework idiom matters, and modern React has purpose-built tools for it: useTransition gives you an isPending flag without managing a boolean yourself, and inside a form useFormStatus exposes the parent form's pending state to a nested submit button — which is exactly the case that used to require prop-drilling. Vue reaches for a ref plus onBeforeUnmount; Svelte a plain let and the cleanup returned from onMount. One trap is universal: clear the previous timeout before setting a new one, or a rapid re-click leaves a stale timer that flips the button back to idle while a second request is still running. For Tailwind the states map to data-[state=pending]: variants, which keeps the whole machine in markup.