flashing fixed
This commit is contained in:
Vincent van der Wal
+10
-12
@@ -1,7 +1,7 @@
|
||||
import { tick } from 'svelte';
|
||||
|
||||
import {
|
||||
isViewTransitionActive,
|
||||
canStartViewTransition,
|
||||
prefersReducedMotion,
|
||||
startViewTransition,
|
||||
supportsViewTransitions
|
||||
@@ -22,23 +22,21 @@ import {
|
||||
* page (see view-transition.ts).
|
||||
*/
|
||||
export async function runDayTransition(update: () => void): Promise<void> {
|
||||
if (!supportsViewTransitions() || prefersReducedMotion() || isViewTransitionActive()) {
|
||||
if (!canStartViewTransition()) {
|
||||
update();
|
||||
return;
|
||||
}
|
||||
|
||||
const root = document.documentElement;
|
||||
root.classList.add('day-switch');
|
||||
try {
|
||||
// Svelte applies the change on the next tick; the transition has to wait
|
||||
// for that before it snapshots the new state.
|
||||
await startViewTransition(async () => {
|
||||
// Svelte applies the change on the next tick; the transition has to wait for
|
||||
// that before it snapshots the new state. `day-switch` scopes which regions
|
||||
// take part (see routes/layout.css) and is cleared for us when it ends.
|
||||
await startViewTransition(
|
||||
async () => {
|
||||
update();
|
||||
await tick();
|
||||
});
|
||||
} finally {
|
||||
root.classList.remove('day-switch');
|
||||
}
|
||||
},
|
||||
{ rootClass: 'day-switch' }
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
|
||||
@@ -1,24 +1,40 @@
|
||||
/**
|
||||
* One view transition at a time.
|
||||
* Central entry point for every view transition in the app.
|
||||
*
|
||||
* The browser runs exactly one: starting a second while the first is still on
|
||||
* screen *skips* the first, which drops its frozen snapshot on the spot and
|
||||
* pops the live DOM into view. That is the whole-screen flash, and overlapping
|
||||
* transitions are the normal case here rather than an edge case:
|
||||
* Two things it exists to get right.
|
||||
*
|
||||
* - `/` and every bare `/weather/<view>/` page is a redirect stub that calls
|
||||
* `goto` from `onMount`, so one click on a nav entry produces two (from the
|
||||
* root, three) navigations back to back - and the stub renders nothing, so
|
||||
* the frame it exposes is an empty page;
|
||||
* - a theme toggle or a day switch can land while a navigation is still
|
||||
* waiting for its forecast.
|
||||
* **One transition at a time, but only where it matters.** Starting a
|
||||
* transition while another is running makes the browser skip the first, and
|
||||
* what that looks like depends entirely on which phase the first is in:
|
||||
*
|
||||
* Letting a second update ride along inside the transition that is already
|
||||
* running keeps one continuous cross-fade across the whole chain.
|
||||
* - *capturing* - its update callback has not resolved yet, so the screen is
|
||||
* frozen on the outgoing snapshot. Skipping drops that snapshot on the spot
|
||||
* and pops the half-updated live DOM into view: the whole-screen flash.
|
||||
* This phase is common here, because navigation deliberately holds the
|
||||
* callback open while the new page fetches, and `/` plus every bare
|
||||
* `/weather/<view>/` page is a redirect stub that navigates again from
|
||||
* `onMount` - one click, two or three navigations.
|
||||
* - *animating* - the DOM is already in its final state and the pseudo
|
||||
* elements are playing out. Skipping just finishes them early, landing on
|
||||
* exactly the state they were heading for.
|
||||
*
|
||||
* So a new transition rides along inside the running one only while it is
|
||||
* capturing; once it is animating, superseding it is the better answer (waiting
|
||||
* would strand the new update under a stale snapshot until the animation ends).
|
||||
*
|
||||
* **A scoping class.** `rootClass` is set on `<html>` for the life of the
|
||||
* transition, so the stylesheet can tell a page swap from a day switch and pin
|
||||
* the parts that are identical on both sides (see routes/layout.css).
|
||||
*/
|
||||
type UpdateCallback = () => void | Promise<void>;
|
||||
|
||||
let active: Promise<void> | null = null;
|
||||
interface Options {
|
||||
/** Class set on `<html>` while the transition runs, for scoping CSS. */
|
||||
rootClass?: string;
|
||||
}
|
||||
|
||||
/** Set while a transition holds the screen frozen on the outgoing snapshot. */
|
||||
let capturing: Promise<void> | null = null;
|
||||
|
||||
export const supportsViewTransitions = (): boolean =>
|
||||
typeof document !== 'undefined' && typeof document.startViewTransition === 'function';
|
||||
@@ -26,20 +42,25 @@ export const supportsViewTransitions = (): boolean =>
|
||||
export const prefersReducedMotion = (): boolean =>
|
||||
typeof window !== 'undefined' && window.matchMedia('(prefers-reduced-motion: reduce)').matches;
|
||||
|
||||
/** True while a transition is on screen, from capture until its animation ends. */
|
||||
export const isViewTransitionActive = (): boolean => active !== null;
|
||||
/**
|
||||
* True while a transition is frozen on its outgoing snapshot - the phase in
|
||||
* which starting a rival transition would flash the page.
|
||||
*/
|
||||
export const isViewTransitionCapturing = (): boolean => capturing !== null;
|
||||
|
||||
/** Whether `startViewTransition` would actually open one right now. */
|
||||
export const canStartViewTransition = (): boolean =>
|
||||
supportsViewTransitions() && !prefersReducedMotion() && !isViewTransitionCapturing();
|
||||
|
||||
/**
|
||||
* Runs `update` inside a view transition, or straight away when one cannot (or
|
||||
* must not) be started. Resolves once the transition has finished animating -
|
||||
* or as soon as the update is done, when it ran on its own.
|
||||
*
|
||||
* Callers that need to know which of the two happened should check
|
||||
* `isViewTransitionActive()` first; the point of this function is that they
|
||||
* mostly should not care.
|
||||
*/
|
||||
export function startViewTransition(update: UpdateCallback): Promise<void> {
|
||||
if (!supportsViewTransitions() || prefersReducedMotion() || active) {
|
||||
export function startViewTransition(update: UpdateCallback, options: Options = {}): Promise<void> {
|
||||
const { rootClass } = options;
|
||||
|
||||
if (!canStartViewTransition()) {
|
||||
return Promise.resolve(update()).then(
|
||||
() => {},
|
||||
(error: unknown) => {
|
||||
@@ -48,25 +69,33 @@ export function startViewTransition(update: UpdateCallback): Promise<void> {
|
||||
);
|
||||
}
|
||||
|
||||
const root = document.documentElement;
|
||||
if (rootClass) root.classList.add(rootClass);
|
||||
|
||||
const transition = document.startViewTransition(update);
|
||||
|
||||
// A throw inside the callback rejects `updateCallbackDone` as well as
|
||||
// `finished`. Nothing awaits the former, and an unhandled rejection there is
|
||||
// what turns one bad render into an "Uncaught" error on the page.
|
||||
transition.updateCallbackDone.catch((error: unknown) => {
|
||||
const captured = transition.updateCallbackDone.then(
|
||||
() => {},
|
||||
(error: unknown) => {
|
||||
console.error('view transition update failed', error);
|
||||
}
|
||||
);
|
||||
capturing = captured;
|
||||
void captured.then(() => {
|
||||
if (capturing === captured) capturing = null;
|
||||
});
|
||||
|
||||
// A superseded transition rejects `finished`; the DOM is already up to date,
|
||||
// so that is not an error worth surfacing - but the slot has to be freed.
|
||||
const done = transition.finished.then(
|
||||
// so that is not an error worth surfacing.
|
||||
return transition.finished
|
||||
.then(
|
||||
() => {},
|
||||
() => {}
|
||||
);
|
||||
active = done;
|
||||
void done.then(() => {
|
||||
if (active === done) active = null;
|
||||
)
|
||||
.finally(() => {
|
||||
if (rootClass) root.classList.remove(rootClass);
|
||||
});
|
||||
|
||||
return done;
|
||||
}
|
||||
|
||||
@@ -14,8 +14,7 @@
|
||||
import { storedTheme } from '$lib/stores/settings';
|
||||
|
||||
import {
|
||||
isViewTransitionActive,
|
||||
prefersReducedMotion,
|
||||
canStartViewTransition,
|
||||
startViewTransition,
|
||||
supportsViewTransitions
|
||||
} from '$lib/utils/view-transition';
|
||||
@@ -54,7 +53,7 @@
|
||||
return;
|
||||
}
|
||||
|
||||
if (supportsViewTransitions() && !isViewTransitionActive()) {
|
||||
if (canStartViewTransition()) {
|
||||
// one cross-fade of the whole document; component transitions untouched
|
||||
void startViewTransition(paint);
|
||||
return;
|
||||
@@ -206,13 +205,13 @@
|
||||
else markPageReady();
|
||||
|
||||
// `startViewTransition` decides whether a transition is possible at all
|
||||
// (support, reduced motion, one already on screen) and runs the update
|
||||
// (support, reduced motion, one already capturing) and runs the update
|
||||
// inline when it is not - so there is exactly one path from here down.
|
||||
const underTransition =
|
||||
supportsViewTransitions() && !prefersReducedMotion() && !isViewTransitionActive();
|
||||
const underTransition = canStartViewTransition();
|
||||
|
||||
return new Promise<void>((swap) => {
|
||||
void startViewTransition(async () => {
|
||||
void startViewTransition(
|
||||
async () => {
|
||||
// hand control back so SvelteKit swaps the DOM underneath the
|
||||
// frozen snapshot of the old page
|
||||
swap();
|
||||
@@ -221,7 +220,10 @@
|
||||
// and leaving it unhandled shows up as "navigation aborted".
|
||||
await navigation.complete.catch(() => {});
|
||||
if (pending) await waitForContent(underTransition);
|
||||
});
|
||||
},
|
||||
// pins the chrome that is the same on both sides (routes/layout.css)
|
||||
{ rootClass: 'page-switch' }
|
||||
);
|
||||
});
|
||||
});
|
||||
|
||||
@@ -315,7 +317,7 @@
|
||||
|
||||
<div class="flex h-screen overflow-hidden bg-background text-foreground">
|
||||
<!-- Desktop sidebar -->
|
||||
<div class="hidden h-full shrink-0 md:block">
|
||||
<div class="sidebar-region hidden h-full shrink-0 md:block">
|
||||
<WeatherNav collapsed={sidebarCollapsed} onToggle={toggleSidebar} />
|
||||
</div>
|
||||
|
||||
|
||||
+63
-30
@@ -159,25 +159,27 @@
|
||||
z-index: 20;
|
||||
}
|
||||
|
||||
/* Same for the topbar: a captured region's snapshot is painted at its layout
|
||||
position, including the part normally scrolled up behind the chrome. */
|
||||
:root.day-switch .topbar {
|
||||
/* Same for the topbar and the sidebar: a captured region's snapshot is
|
||||
painted at its layout position, including the part normally scrolled up
|
||||
behind the chrome. Both are also identical either side of a *page* swap,
|
||||
so they are captured there too and pinned below - a region that does not
|
||||
change should not be animated at all. */
|
||||
:root.day-switch .topbar,
|
||||
:root.page-switch .topbar {
|
||||
view-transition-name: topbar;
|
||||
}
|
||||
::view-transition-group(topbar) {
|
||||
z-index: 30;
|
||||
}
|
||||
|
||||
::view-transition-old(day-table),
|
||||
::view-transition-new(day-table),
|
||||
::view-transition-old(day-summary),
|
||||
::view-transition-new(day-summary),
|
||||
::view-transition-old(day-charts),
|
||||
::view-transition-new(day-charts) {
|
||||
animation-duration: 420ms;
|
||||
animation-timing-function: ease;
|
||||
:root.page-switch .sidebar-region {
|
||||
view-transition-name: sidebar;
|
||||
}
|
||||
::view-transition-group(sidebar) {
|
||||
z-index: 25;
|
||||
}
|
||||
|
||||
/* The root fade is the page swap's own; during a day switch the chrome must
|
||||
not so much as flicker, so it is cancelled outright. */
|
||||
:root.day-switch::view-transition-old(root),
|
||||
:root.day-switch::view-transition-new(root) {
|
||||
animation: none;
|
||||
@@ -188,35 +190,66 @@
|
||||
.day-region-summary,
|
||||
.day-region-charts,
|
||||
.daystrip,
|
||||
.topbar {
|
||||
.topbar,
|
||||
.sidebar-region {
|
||||
view-transition-name: none;
|
||||
}
|
||||
}
|
||||
|
||||
/* Whole-document cross-fade, for both a page swap and a theme change (see
|
||||
routes/+layout.svelte). Doing the theme as a view transition instead of a
|
||||
blanket `* { transition }` matters: that blanket rule also stretched every
|
||||
component's own hover and focus transitions to 400ms for the duration of
|
||||
the switch, which read as lag on interactive controls.
|
||||
/* ── Cross-fades that do not dip ──────────────────────────────────────────
|
||||
The default cross-fade is NOT opacity-neutral: both snapshots are opaque
|
||||
and the browser fades one out while fading the other in, so at the
|
||||
midpoint the pair covers only ~75% of the region and the page background
|
||||
shows through both. That dip is the flash - over the whole viewport for a
|
||||
page swap, and over the table, summary and charts (which between them are
|
||||
the whole content column) for a day switch.
|
||||
|
||||
The default cross-fade is NOT opacity-neutral. Both snapshots are opaque
|
||||
and the browser fades one out while fading the other in, so halfway
|
||||
through, the two together cover only ~75% of the screen and the page
|
||||
background shows through everything: the whole screen visibly dips, which
|
||||
reads as a flash. Holding the outgoing snapshot at full opacity and fading
|
||||
only the incoming one in on top of it (it is painted above) keeps every
|
||||
frame fully covered. */
|
||||
::view-transition-old(root) {
|
||||
The only opacity-neutral pairing with normal blending is to hold the
|
||||
outgoing snapshot at full opacity and fade the incoming one in on top of
|
||||
it - it is painted above - so every frame stays fully covered. */
|
||||
@keyframes vt-fade-in {
|
||||
from {
|
||||
opacity: 0;
|
||||
}
|
||||
}
|
||||
|
||||
::view-transition-old(root),
|
||||
::view-transition-old(day-table),
|
||||
::view-transition-old(day-summary),
|
||||
::view-transition-old(day-charts) {
|
||||
animation: none;
|
||||
opacity: 1;
|
||||
}
|
||||
::view-transition-new(root) {
|
||||
animation: root-fade-in 400ms ease;
|
||||
animation: vt-fade-in 400ms ease;
|
||||
}
|
||||
@keyframes root-fade-in {
|
||||
from {
|
||||
opacity: 0;
|
||||
::view-transition-new(day-table),
|
||||
::view-transition-new(day-summary),
|
||||
::view-transition-new(day-charts) {
|
||||
animation: vt-fade-in 420ms ease;
|
||||
}
|
||||
|
||||
/* The outgoing snapshot no longer fades, so a region that gets *shorter*
|
||||
would keep showing its old tail below the new content for the whole
|
||||
transition. Clipping to the group - which animates between the two sizes -
|
||||
turns that into the shrink it actually is. */
|
||||
::view-transition-group(day-table),
|
||||
::view-transition-group(day-summary),
|
||||
::view-transition-group(day-charts) {
|
||||
overflow: clip;
|
||||
}
|
||||
|
||||
/* Chrome that is identical on both sides of the swap: pinned, never faded.
|
||||
(Whole-document theme changes are a `root` transition with no page-switch
|
||||
class, so they still cross-fade the chrome along with everything else.) */
|
||||
::view-transition-old(topbar),
|
||||
::view-transition-new(topbar),
|
||||
::view-transition-old(sidebar),
|
||||
::view-transition-new(sidebar),
|
||||
::view-transition-old(daystrip),
|
||||
::view-transition-new(daystrip) {
|
||||
animation: none;
|
||||
opacity: 1;
|
||||
}
|
||||
|
||||
/* Fallback for browsers without view transitions: fade the colours only. */
|
||||
|
||||
Reference in New Issue
Block a user