36 Tailwind CSS Modals

Every dialog demo opens with the native <dialog> element and its showModal() method, which gives you a real top-layer overlay, a free backdrop via ::backdrop, and Escape-to-close for nothing. Tailwind v4 drives the entrance through the starting: variant, which compiles to a @starting-style block: you write the open state as normal classes (opacity-100 scale-100) and the pre-open state as starting:opacity-0 starting:scale-95, the value the browser reads the instant the element enters the top layer. A transition utility bridges the two. The common trap is the exit: @starting-style only fires on the way in, so a plain close snaps the dialog shut with no fade. You need transition-discrete (which emits transition-behavior: allow-discrete) so the browser keeps the element painted while display and the top-layer membership animate out. That single utility is the difference between a smooth close and a flicker.

Yes, and the trick is moving the state up the tree instead of onto the toggled element. The age gate (demo 03) and the cm/inch size toggle (demo 08) both hang a hidden checkbox or radio near the top of the component, then let an ancestor react with has-checked: — Tailwind's compile target for :has(:checked). So the wrapper says has-checked:pointer-events-none has-checked:opacity-0 and the whole gate dismisses when the box flips, no handler required. The unit toggle swaps two columns by pairing peer/has-checked: with hidden so only one measurement set is in flow at a time. Two things to watch: the input must be a real focusable control with a paired <label> so keyboard users can toggle it, and :has() has no old-browser fallback — a visitor on an engine without it sees the gate stuck open. For a hard legal gate that is a reason to keep a server check as well; for a UI convenience it is fine.

This is the most common modal bug and the native <dialog> only half-solves it. showModal() makes the rest of the document inert, so clicks and Tab are blocked behind the overlay, but it does not stop wheel and touch scrolling of the underlying <body> — the page still moves under the dim backdrop. The drawers and slide-overs here (demos 06 and 15) lock it by toggling overflow-hidden on the root element when the dialog opens and removing it on close. On iOS overflow-hidden alone can still rubber-band; if you see that, also set overscroll-contain on the scrollable panel inside the modal so the scroll chain stops at the panel edge. Avoid position: fixed body hacks — they reset scroll position on close and cause a visible jump. And restore the class in the dialog's close event, not the click handler, so Escape and backdrop dismissal both unlock the page instead of leaving it frozen.

Native <dialog> opened with showModal() gives you a lot: it exposes an implicit role="dialog" with aria-modal, traps Tab inside the open dialog, makes the rest of the page inert, and closes on Escape. What it does not do is label itself or move focus intelligently. Point aria-labelledby at the heading so screen readers announce what opened, and set initial focus on the first meaningful control — the auth modal (demo 01) focuses the email field, the destructive delete (demo 11) focuses the type-to-confirm input, not the dangerous button. On close, return focus to the trigger that opened it, or the user is dumped at the top of the document. For the zero-JS :target lightbox and :has() gates you get none of the native trapping, so those need a real close control in the tab order and a visible focus-visible: ring. Icon-only close buttons always need an aria-label; a bare × is silent.

The neat part of demo 18 is that the highlighted row is derived, not stored. Each result is a real button in a list, and the palette uses roving selection: arrow keys move focus with focus() and the active look comes from focus-visible: plus sibling-aware variants, so the browser's own focus is the selection — there is no selectedIndex to keep in sync. Enter runs whatever is focused. Filtering as you type is the only piece that touches JS: it hides non-matching rows with a hidden class rather than removing them, which keeps the DOM order stable so arrow-walking never jumps. Opening on ⌘K means a keydown listener that checks event.metaKey (and ctrlKey for Windows) and calls preventDefault() — browsers bind ⌘K to the address bar, so skip that and the palette never opens. Remember to unbind or guard the listener when the dialog is closed so the shortcut does not fight other views.

The :target gallery (demo 09) is genuinely zero-JS: each full-screen frame is an element whose id becomes the URL hash when you click its link, and target: variants show the matching panel while hiding the rest. It is perfect when you want the viewer to be linkable and survive with scripting disabled — a shared URL opens straight to that image. The trade-offs are real, though. Every open and close writes to the browser history, so the back button steps through each frame instead of leaving the page, which surprises people. It also fights other in-page anchors, since any #id navigation now competes for the same mechanism, and it cannot trap focus or mark the background inert the way a native <dialog> does. Use :target for a lightweight, deep-linkable image viewer; reach for the <dialog>-based modals when you need focus management, scroll lock, or a close that does not pollute history.

Two different zero-controller patterns. The settings modal (demo 17) uses radio tabs: one hidden radio group, a <label> for each tab, and the panels shown or hidden with peer/has-checked: variants. Because only one radio in a group can be checked, exactly one panel is ever visible — the browser enforces the mutual exclusion for free, and Tab plus arrow keys already navigate a radio group, so keyboard support comes with it. The onboarding tour (demo 14) is not pure CSS — it keys off a data-step attribute on the dialog and Tailwind's data-[step=2]: style variants, with tiny JS that only increments the attribute on Next. That is deliberate: a three-way step needs a value that can move forward, back, and skip, which radios model awkwardly. The mistake to avoid is styling the panels with hidden only via opacity — a display:none-equivalent (hidden) must win, or a screen reader reads all three panels at once.

The native <dialog> with showModal(), ::backdrop, and top-layer rendering is well supported across current engines, and the @starting-style and transition-discrete animation utilities used here are the newer piece — they enhance the entrance but degrade to an instant open on an engine that lacks them, so nothing breaks. The bigger question is whether a modal is the right control. Do not trap something the user needs to reference against the page behind it, and do not modal-gate content a search engine or a linked visitor should reach — the paywall (demo 04) and age gate (demo 03) are intentional friction, but the same pattern applied to ordinary content just hides it. Prefer the slide-over drawer (demo 06) or the filter sheet (demo 15) when the task is a companion to the page rather than a hard interrupt, and inline the GDPR consent as a corner sheet (demo 13), not a blocking overlay, so it never stops a first-time visitor from reading anything.