/* ========================================================================== SCROLL SNAP — optional add-on (demo) ========================================================================== Load AFTER main.css to make every track and every red question "snap" into the centre of the screen when scrolling stops — on phones only; desktop and tablets keep free scrolling (see 0.). Remove the and everything is exactly as before — main.css is not touched. This is pure CSS (CSS Scroll Snap, supported in all browsers since ~2019/2020). No JavaScript involved: main.js keeps working unchanged and simply picks the video that has snapped into the centre. How it works ------------ • The SCROLL CONTAINER declares that it snaps and how strictly: scroll-snap-type: y mandatory; The scroll container of a normal page is the viewport, and the viewport takes this property from the element. • The ELEMENTS INSIDE declare where they want to be caught: scroll-snap-align: center; → when scrolling stops, the browser moves to the nearest snap point so that this element's centre sits in the viewport's centre. • Elements with position: fixed (the portrait header, the background video, the gradient) don't scroll, so they never act as snap points. The rules live in their own cascade layer "snap". It is declared after the layers from main.css, so it wins over them without !important. ========================================================================== */ @layer snap { /* ------------------------------------------------------------------------ 0. Phones only ------------------------------------------------------------------------ Everything below only applies on PHONES. Desktop AND tablets (incl. the iPad mini) get the desktop behaviour: free scrolling as before. A phone = a touchscreen AND a small screen. Two conditions: a) Touch is the main input: "hover: none" → the primary input can't hover (a finger) "pointer: coarse" → the primary input is imprecise (a finger) A laptop with a touchscreen still reports its trackpad/mouse here (hover + fine), so it never snaps — however small its window is. b) The SHORTER side of the screen is at most 600px: "max-width: 600px" → a phone held upright "max-height: 600px" → a phone held sideways Reference sizes (CSS pixels, upright): biggest phones (iPhone Pro Max, large Androids) ~ 440 × 956 smallest tablet (iPad mini) ~ 744 × 1133 600px sits safely in the gap: every phone is below it in at least one direction, every iPad is above it in both directions (iPad mini sideways: 1133 × 744 → still no snapping). The comma means "or": the block applies if a) AND (upright OR sideways small). a) has to be repeated because each part of a comma list is its own complete query. Testing on desktop: Chrome DevTools → device toolbar (phone icon), pick a phone → snapping; pick "iPad Mini" → no snapping. */ @media (hover: none) and (pointer: coarse) and (max-width: 600px), (hover: none) and (pointer: coarse) and (max-height: 600px) { /* ------------------------------------------------------------------------ 1. The scroll container ------------------------------------------------------------------------ "mandatory": when scrolling stops, the browser ALWAYS snaps to a snap point → there is always a track or a question exactly in the centre. That matches the idea "a video is always in view". The alternative is "proximity": the browser only snaps when you stop NEAR a snap point; in between it leaves you where you are. Feels less strict — worth trying out (just swap the keyword). */ html { scroll-snap-type: y mandatory; } /* ------------------------------------------------------------------------ 2. The snap points ------------------------------------------------------------------------ */ /* The snap point of a track is an invisible ::after layer that covers the
exactly (inset: 0 → same top and bottom as the video, because the article has no vertical padding). Its centre = the video's centre. CHANGED (14.10.2026): previously ".track__video" itself snapped. Problem on iOS Safari: after snapping, the track hopped a few pixels upwards. Cause: wheel.css transforms the video (tilt + perspective). WebKit measures a snap area INCLUDING its transform — a tilted facet seen in perspective is a trapezoid whose bounding box is not centred on the facet's real centre. So the snap target was calculated with a slightly wrong centre while the video was still tilted; once it came to rest (now flat), WebKit re-measured and corrected itself → the visible hop. (Chrome doesn't show it.) Why not snap the
itself? It isn't transformed, but its snap area includes its scroll-margin-top (main.css, for the centred clock jump) → the centre would sit far too high. The ::after layer has neither: not transformed (wheel.css only transforms the article's real child elements, "> *", which never matches a pseudo-element) and no scroll-margin. So its centre never moves, whatever the drum does. It sits invisibly on top of the video; "pointer-events: none" lets taps go through to the video. Clock jumps keep working as before: the browser scrolls to the article (centred via its scroll-margin-top from main.css), and the nearest snap point there is exactly that track's centre. The questions still snap themselves (they have no untransformed wrapper). If they hop too, they need a wrapper element in the HTML — see NOTIZEN.md. */ .track::after { content: ""; position: absolute; inset: 0; pointer-events: none; scroll-snap-align: center; } .question { scroll-snap-align: center; } /* Optional: "always" forbids a fast flick from skipping a track — every track has to be passed one by one. Makes skimming through 24 tracks tedious, therefore off by default. Try it: */ /* .track::after { scroll-snap-stop: always; } */ /* With "mandatory", every place you should be able to rest at needs a snap point — including the very top (clock) and the credits. */ .site-header { scroll-snap-align: start; /* landscape: the full-screen clock */ } .site-footer { scroll-snap-align: center; } /* ------------------------------------------------------------------------ 3. Portrait: a resting point at the top of the page ------------------------------------------------------------------------ In portrait the header is position: fixed, so it is no snap point. The space at the top of the page (where you see the big mute button) is the 100vh margin-top of the first track. Without a snap point there, "mandatory" would always pull you down to track 01. Solution: an invisible, exactly screen-high placeholder at the top of
(a ::before pseudo-element, so no extra HTML) that acts as the snap point "top of the page". Why exactly one screen high? Snap areas TALLER than the screen are treated specially: the browser may also rest at their bottom edge or anywhere inside them. (A first attempt — giving the first track scroll-margin-top: 100vh — produced exactly that: an extra resting point halfway into track 01.) Why doesn't it push the layout down? The negative margin-bottom (-100vh) and the first track's margin-top (+100vh, from main.css) are "adjoining margins" and collapse into one: -100vh + 100vh = 0. So the first track still starts exactly one screen height below the top. */ @media (orientation: portrait) { .site-main::before { content: ""; display: block; height: 100vh; margin-bottom: -100vh; scroll-snap-align: start; } } } }