Building a TikTok-style looping video feed (one autoplaying card at a time, crossfading audio between cards) surfaces three WebKit behaviors that Chrome's autoplay documentation will not prepare you for. Symptoms: sound randomly 're-muting' mid-scroll, sound always lost after page navigation, and the first video of a page load ending up paused instead of playing. All three were verified against Safari-family policy and reproduced/fixed in headless Chromium plus production Safari.
First: user activation is per-document and dies on every full page load. No browser carries activation across an MPA navigation. Chrome alone permits unmuted autoplay after a same-origin click-through navigation (its engagement exception), so an MPA feed keeps sound in Chrome but never in Safari. The only real fix for Safari is making navigations same-document (a client-side router; in Astro, <ClientRouter />), so the persisting document keeps both its activation history and your module state, and the nav click itself provides fresh transient activation for the first play on arrival.
Second: transient activation is a short timer (~5 s in WebKit, see webkit.org/blog/13862) refreshed by pointerdown/keydown - and wheel/trackpad scrolling never refreshes it. So in a feed where scrolling triggers play() on the next card's fresh <video>, any flip that happens more than ~5 s after the last real input rejects with NotAllowedError. This is why the failure feels intermittent: flips right after a tap or keypress succeed, later ones fail. The durable fix is WebKit's per-element grant model (webkit.org/blog/7734): once an element has been played from a real gesture, that element keeps its audible-playback right for the session. Instead of one <video> per card, route all playback through a small persistent pool (front/back pair, src-swapped and crossfaded), and 'bless' every pooled element inside a capture-phase pointerdown/keydown handler by calling play() (or load() for elements without a src) during the gesture. One real tap licenses audible playback for the rest of the session regardless of scroll distance.
Third, the silent-start trap: WebKit will happily allow an unmuted play() at volume = 0 - and then auto-pause the video at the moment your fade-in makes it audible without a gesture. If you implement crossfades as 'start at volume 0, ramp to 1', a fresh page load plays for ~250 ms and freezes. Gate the fade on navigator.userActivation.hasBeenActive: when false (fresh document, no gesture yet), attempt play() at full volume so the browser adjudicates audibility atomically at call time - either sound is allowed and persists, or you get a clean NotAllowedError to catch and degrade to muted playback with a truthful mute icon. Never let an inaudible start succeed only to be killed mid-fade.
Two smaller notes from the same work. Detach a pooled media element from the DOM before re-sourcing it for preload: an element still parented in the previous card's container repaints its poster the instant src changes, flashing the wrong poster. And 'volume-up key to unmute' cannot be built for Safari: macOS/iOS consume hardware volume keys before the page sees them, the Media Session API defines no volume actions, and HTMLMediaElement.volume is read-only on iOS.
Recommendation: treat Chrome's behavior as the exception, not the baseline. Design for WebKit's model - per-element grants, a persistent blessed pool, same-document navigation, full-volume atomic play attempts on gestureless documents with NotAllowedError as the muted-degrade signal - and Chrome works automatically.