Browser support

Browser	Spring easing	Compositor-driven backdrop dim + `--scrollsheet-progress`
Chrome / Edge	113+	115+
Safari	17.2+	26+
Firefox	112+	behind a flag, see below

The backdrop dim and --scrollsheet-progress run as CSS scroll-driven animations (animation-timeline: scroll()) on engines that support them, off the main thread entirely, feature-detected once and stamped data-scrollsheet-sda on the dialog. Firefox has animation-timeline: scroll() implemented but still ships it behind a flag as of mid-2026, and Safari 17.2 through 25 has the spring but not scroll-driven animations yet; on both, and on every other engine below the compositor floor, the same values still update every frame from onTravel’s own JS write instead, main thread rather than the compositor. Two pieces stay JS-driven on every engine regardless: a stacked sheet’s parent-panel recede (the parent panel lives in a sibling top-layer <dialog>, not a descendant the track’s timeline can reach) and backgroundEffect (its target is an arbitrary page element outside the dialog entirely).

Where dialog.closedBy exists (Chrome/Edge 134+, Firefox 141+), a modal sheet sets closedby to closerequest when escapeDismissible is on, none when it’s off, so Esc and the Android back gesture route through the platform’s own close-request machinery instead of scrollsheet’s manual handling. Never closedby="any": .scrollsheet-dialog always covers the full viewport, so there’s no “outside the dialog” region for a native light-dismiss to detect, and it would only double-fire against the library’s own backdrop-click handling for no gain. Engines without closedBy (Safari, as of this writing) keep the existing manual Esc/backdrop dismissal, unchanged. Non-modal sheets (modal={false}) don’t get a platform close watcher for free the way a modal showModal() dialog does, so a dismissible one creates its own via CloseWatcher (Chrome 144+) so Android back closes it instead of navigating the page. Touch-primary devices only: Esc is also a platform close signal wherever CloseWatcher exists, and non-modal Esc is deliberately scoped to focus inside the sheet, so a desktop watcher would steal the page’s Esc. Real-device verification on that path is still pending.

Without `<dialog>`

~4% of browsers (Opera Mini, old in-app WebViews, iOS ≤15.3)
You get	A fixed-position modal: backdrop, tap-to-close, Escape, focus moved into the panel on open and restored to the trigger on close, body scroll locked. Panel sizes to content up to 85% of the viewport, then scrolls internally
Gone	Detents, drag, the enter/exit animation, the top layer (panel portals to `<body>` with a max `z-index` instead of a guarantee), the native focus trap. `Sheet.Handle` renders nothing
Still works	Every `--scrollsheet-*` theming variable (`-bg`, `-fg`, `-radius`, `-shadow`, `-backdrop`, safe-area) resolves the same way. `isSupported()` reports which path a browser takes

The trade against libraries that portal a plain <div> (vaul, react-modal-sheet): their full gesture experience reaches these browsers and ours does not, on the bet that the top layer is worth more on the 96% than the gestures are on the 4%.

API referenceFull prop reference for Sheet.Root, the styling hooks on Sheet.Content, and every other named export.

Browser support

Without <dialog>

Without `<dialog>`