20 CSS Empty States

Three things, and most production empty states manage one. First, say what happened in terms the user recognises — "No results for merino socks" beats "No data", because it confirms the system heard the request rather than implying something broke. Second, offer the next action, and make it the obvious one: clear the filters, create the first project, continue shopping. An empty state with no action is a dead end, and the user's only remaining move is the back button. Third, match the tone to the cause. An empty inbox is an achievement and can be quietly celebratory; a failed network request is a problem and needs a retry button, not a friendly illustration. The common failure is treating all three cases identically — a cheerful mascot on a permission-denied screen reads as the interface making light of something the user cannot fix.

The core requirement is that the change is announced, not just rendered. When a list empties because a filter matched nothing, a sighted user sees the swap instantly while a screen reader user hears nothing at all unless you tell it to speak. Wrap the count or status in a live region — role="status", or aria-live="polite" — and write the new text into it when the state changes. Two details make the difference between working and not: the live region must already exist in the DOM before you write to it, because injecting the region and its content together announces nothing; and it must be polite rather than assertive for a routine result count, since assertive interrupts whatever the user is currently hearing. Keep the announcement short and factual — "No results for merino socks" — rather than reading out the whole empty state including the illustration alt text and the button label.

Put a single row in the <tbody> with one cell spanning every column, using colspan set to the column count. That keeps the table structurally valid, which matters more than it looks: a <div> dropped inside a <tbody> is invalid HTML, and browsers will hoist it out of the table entirely, so your carefully centred empty state ends up rendering above or below the table rather than inside it. Centring the content is then a matter of giving that one cell some vertical padding and a text-align. Two things worth getting right: keep the table header visible so the user can still see what columns exist and what they were filtering on, and if the emptiness is caused by a filter rather than by genuinely having no data, say so and offer to clear it — those are different situations and deserve different copy.

Sometimes, and rarely the way stock illustration packs suggest. An illustration earns its place when it makes the state instantly recognisable — an empty cart, an empty inbox — and it costs its place when it delays the message, pushes the action below the fold, or adds a network request to a screen that is already the result of something not loading. That last point matters more than it sounds: an empty state caused by a failed fetch should not itself depend on fetching a 200KB SVG. Drawing the graphic in CSS avoids that entirely and keeps the whole component in one file. Where an illustration is decorative rather than informative, mark it aria-hidden="true" so screen readers skip straight to the text — otherwise assistive technology announces a description of a picture before it reaches the sentence that actually explains what happened.

Reserve the space before either one renders. The shift happens because the skeleton and the empty state are different heights, so the moment you swap them everything below jumps — and that jump is a Cumulative Layout Shift event, which Core Web Vitals measures and Google uses. The fix is to give the container a min-height sized to the taller of the two states, so the box is stable and only its contents change. From there the swap can be a cross-fade rather than a hard cut, which reads as calmer: @starting-style with transition-behavior: allow-discrete animates an element that is entering or leaving display: none, which plain transitions cannot do. Both are progressive enhancement — without them the states swap instantly, which is still correct, just less smooth.

They answer three different questions and should never share one component. A loading state says "this is coming" — the request is in flight and the outcome is unknown, so a skeleton or spinner is honest. An empty state says "this worked and there is nothing here" — the request succeeded and returned zero results, which is a normal outcome and often the user's own doing, like an over-narrow filter. An error state says "this did not work" — something failed, the user is not at fault, and there must be a retry path. Conflating them produces the two most common bugs in this area: showing an empty state while data is still loading, which makes a working app look broken, and showing an empty state after a failed request, which quietly hides the failure and leaves the user with no way to recover.

Listen for the online and offline events on window and reflect the current value of navigator.onLine in your UI. The important caveat is that navigator.onLine only tells you whether the device has a network interface up — it says nothing about whether your server is reachable, so a captive portal, a DNS failure or a downed API all report as online. Treat it as a hint rather than a truth: use it to show a banner immediately when connectivity drops, but rely on actual request failures to drive the per-component error states. Two things make the pattern feel considered rather than alarming: keep any content you already have on screen rather than replacing it with an offline screen, and queue the user's pending actions so they are not lost, telling them plainly that the actions will send when the connection returns.

The CSS ports unchanged — every .est-NN selector and custom property is framework-agnostic, and six of the twenty demos need no JavaScript at all. Where a demo does use script, it drives the trigger rather than the styling: filtering a list to zero, failing a fetch, clearing a cart. In a framework that logic is already yours, so what you take from these demos is the markup and the CSS. The one pattern worth copying carefully is the live region: in React, render the region unconditionally and change only its text content, because conditionally mounting the whole region on empty means the announcement fires as the node is created and screen readers frequently miss it. Vue and Svelte have the same trap. For Tailwind the states map to conditional classes as usual, and the min-height that prevents layout shift between the skeleton and the empty state is worth keeping as an explicit utility rather than leaving to chance.