/* ============================================================================ SCENES — "Look inside it" becomes one held screen instead of a stacked band. THE VERDICT THIS ANSWERS (owner, 2026-09-02): "Thoroughly analyze and fix spacing, so much wasted space, much too much scrolling, this is unfortunately looking like a website built in 2010 — where are we going wrong" MEASURED, before this file did anything: the document was 13,025px at 390x844 — 15.4 screens — and .inside was 1,194px of it: a stack of heading, then book, then caption, then two rows of buttons, each waiting its turn down a 390px-wide ribbon. Padding was only 10% of the page, so trimming margins was never going to be the fix. Composing is. press.css and finish.css were being composed at the same time as this, by someone else, and they took the section to 1,113px on their own. THIS FILE NOW ADDS TO THAT NUMBER, ON PURPOSE, and that is the change of 2026-09-03. For three passes it did not, and the price of not adding was that the book was pinned for a ninth of its own scene: "the page doesn't hang on the book section so you just keep scrolling in the book goes away while you're seeing the pages flip". A pinned scene of length N costs N of scroll and there is no version of the arithmetic in which it does not. So the section is now as tall as the deal needs, the cost is measured and written down rather than dressed up, and §2 says what it comes to. Re-measure with tools/harness/headless/hv_scene.py rather than trusting any figure here. WHAT THIS SECTION BECOMES --------------------------------------------------------------------------- The book PINS while the section is passed, and its pages turn with the scroll. The section stops being a band you scroll past and becomes a screen you scroll THROUGH, and the thing you scroll through is the product. The turn is driven by a native CSS scroll-driven animation: .inside carries a view-timeline, and a single registered custom property --bk-p is animated from 0 to 1 across a chosen slice of it. book.js reads --bk-p once per animation frame and hands it to the SAME render() the buttons drive. One renderer, one number, two ways to move it. The alternative — a second, CSS-only page turn built out of keyframes — is two implementations of one object and therefore two things to get wrong, which is the argument book.js itself already makes about WebGL. WHY --bk-p AND NOT A CSS TRANSFORM ON THE LEAF --------------------------------------------------------------------------- The leaf is one sheet now, but it is not one element: two faces, four shading ramps, a cast shadow and a gutter, and the photographs on its two faces change on every turn. CSS keyframes can drive a transform; they cannot re-point a background-image nine times. So CSS owns the SCALAR and book.js owns the OBJECT. WHAT DEGRADES, AND TO WHAT --------------------------------------------------------------------------- Everything here is gated twice: @supports (animation-timeline: view()) in this file, and CSS.supports plus a size check in book.js, which is what adds .bk-scene / .bk-scene-track. Nothing here applies until both agree. - Safari, or any browser without scroll-driven animation: the site exactly as it is today — the book, the drag, Back / Next / Open. - Script off: this file is inert, because the classes are never added, and the page keeps its nine real page photographs in a plain list. - prefers-reduced-motion: the scene is refused in both places. Buttons. - A viewport too short to hold the book AND its controls at a decent size: book.js refuses the scene rather than shrinking the object. See SCENE FLOOR in book.js. HOUSE RULES OBSERVED --------------------------------------------------------------------------- No color literal, and the only paint in the file is one existing hairline token. No shadow of any kind. Nothing is animated that could move the page sideways: the only animated property is a number. ========================================================================== */ /* ========================================================================== 1. THE NUMBERS THE TWO FILES SHARE Registered, so they compute to real values. --bk-p has to be registered as a or it would interpolate discretely and the book would jump between whole leaves instead of turning; --b5r-deal-a and --b5r-deal-b have to be registered as so that animation-range accepts them at all — an unregistered custom property substitutes as an unresolved token, and an animation-range that fails to parse is an animation over the whole cover range, which is the fault this pass is fixing. ========================================================================== */ /* The scroll scalar. 0 is the shut book; 1 is the last page shown here. book.js multiplies it by the number of leaves this machine has — nine on a phone, five when two pages face each other — so this property never has to know which. */ @property --bk-p { syntax: ""; inherits: false; initial-value: 0; } /* WHERE THE DEAL SITS, IN PIXELS ALONG THE SECTION'S OWN VIEW TIMELINE. THIS WAS A PAIR OF PERCENTAGES — entry 12% to exit 88% — and that is the fault the owner reported on 2026-09-03: "the page doesn't hang on the book section so you just keep scrolling in the book goes away while you're seeing the pages flip". A fraction of the section's passage is not the same thing as the stretch the book is actually pinned for, and the two were an order of magnitude apart. MEASURED at 390x844 before this change: the book held still for 176px and the leaves were dealt across 1,528. At 1280x900: 72px against 1,304. He was watching eight ninths of the deal happen to a book that was already on its way off the top of the screen. So the deal is no longer a fraction of anything. book.js measures the pin's own window — where the mount goes under the running head, and how far it can travel inside the section before it has to let go — and writes the two ends of it here as lengths. Nothing else could keep them in step: the window depends on the section's padding, the mount's static offset, the height of the running head and the scroll-padding the telephone bar imposes, and every one of those belongs to another file and moves with the width and with Larger print. See THE TRACK below, and sceneTrack() in book.js. The initial values are a refusal, not a default worth having: if the script never writes them the range is a million pixels long, --bk-p never leaves zero, and the reader gets the book sitting shut with its buttons — which is exactly what a browser with no scroll-driven animation gets. */ @property --b5r-deal-a { syntax: ""; inherits: false; initial-value: 0px; } @property --b5r-deal-b { syntax: ""; inherits: false; initial-value: 1000000px; } @media (prefers-reduced-motion: no-preference) { @supports (animation-timeline: view()) and (animation-range: entry 0% exit 100%) { /* ======================================================================== 2. THE TRACK .bk-scene-track is put on the section by book.js and by nothing else. THE ARITHMETIC OF A PIN, AND WHAT IT ACTUALLY COSTS. A sticky element can only travel inside its containing block's content box. A section whose height is exactly its content therefore offers ZERO travel: the book would be "sticky" and never stick. THE FIRST THREE VERSIONS TRIED TO GET THE PIN FOR NOTHING. The rule was that the pin may spend exactly what the scene saved — the object sized to the free band instead of to 72% of the viewport, the wide "Open the book" row dropped — and the section then came to the same height with the scene and without it, which the harness asserted to the pixel. It was elegant and it was the wrong shape of answer: what the scene saves is about 160px, and a deal of nine leaves is fifteen hundred. There is no arithmetic that gives a pinned scene of length N for less than N of scroll. So the height is now spent on purpose. book.js decides what a leaf should cost in scroll, multiplies by the leaves, adds a settle at each end, and asks for a section exactly tall enough to hold the book still through all of it — and it is not allowed to ask for less than the section would have been anyway, so the composition press.css owns can only be lengthened by this, never shortened. What it comes to is measured and reported rather than hidden: about 1,500px at 390x844 and 960 at 1280x900, on a page of 10,667 and 6,617. WHY THE NUMBER COMES FROM SCRIPT AND NOT FROM A calc() HERE. It depends on the section's padding, on where the mount starts inside it, on the height of the running head and on the scroll-padding the telephone bar imposes — four numbers owned by three other files, all of which move with the width and with Larger print. A constant here — 100svh plus 300, which is what stood first — was a guess about somebody else's layout and was already wrong by 212px at 834x1112. Measuring is not a fallback for not knowing. It is the only thing that stays true when the composition around it moves. min-height, never height: in Larger print the content may be taller than the number and must win. The pin is then short, the deal is longer than the pin, and the pages still turn — worse than the designed case, and still not the fault, because the deal is laid on the pin's own window and shrinks with it. ======================================================================== */ .bk-scene-track { min-height: var(--b5r-track-min, 0px); /* The timeline every part of the scene is measured against. The subject is the SECTION, which is not sticky; a view timeline whose subject was the pinned element would freeze while it was pinned. */ view-timeline-name: --b5r-inside; view-timeline-axis: block; } /* ======================================================================== 3. THE PIN top is written by book.js as --b5r-scene-top, measured off the chrome that is actually on the screen: the 56px running head the masthead collapses into, plus the notch inset. It is not a constant here because it is not a constant there — the running head exists only once motion.js has made the masthead sticky. ======================================================================== */ .bk.bk-scene { position: sticky; top: var(--b5r-scene-top, 4.5rem); /* AND IT SITS IN THE MIDDLE OF THE BAND, NOT AT THE TOP OF IT. Pinned with `top` alone the mount hugs its own content, so the book, its caption and its controls hang from the running head with all the slack piled underneath. Measured at 1280x900: the mount ran 64 to 747 in a 900px window — 64px of air above it and 153 below, and the stage itself sat 246px off the center line of the space it had. The owner: "the book isnt centered vertically when on the page swipes." So the pin takes the whole band between the two persistent bars — the running head above, whose height is already in --b5r-scene-top, and the thumb bar below, which press.css reserves as 5rem of body padding — and centers its wrapped flex lines inside it. `safe` IS LOAD-BEARING. On a short window the book plus caption plus controls can be taller than the band, and unsafe centring would push the top of the book up under the running head where it cannot be scrolled back to. `safe center` falls back to start exactly then, and an engine that does not know the keyword drops the declaration and gets today's behavior — which is the same fallback. */ /* min-height, NOT height. This shipped as `height` for a few hours and that was a real defect: it fixes the box to the band, and when the book, its caption and its controls are TALLER than the band — which happens on any short window, and Safari's toolbars make every iPhone a short window — the content does not shrink, it spills out of the box and prints over whatever section comes next. The owner photographed exactly that: the controls and "Show this page larger" laid across "What happens to your book". min-height keeps everything the centring needs — the box is still at least the band, so `align-content` has room to work with — and takes the failure away, because a box that is too small for its content simply grows. */ min-height: calc(100svh - var(--b5r-scene-top, 4.5rem) - 5rem); align-content: safe center; /* THE SCROLL DRIVES THE NUMBER. Longhands, not the `animation` shorthand: the shorthand resets animation-timeline and animation-range to their initial values, so a shorthand written above them silently un-scrolls the whole scene. */ animation-name: b5r-deal-9; animation-duration: auto; animation-timing-function: linear; animation-fill-mode: both; animation-timeline: --b5r-inside; /* Lengths, not phase percentages, and this is the whole of JOB ONE: the deal is laid on the window the book is actually pinned for. Longhands again, because `animation-range` with a var() on each side would resolve as one shorthand and a single unset value would take the other end with it. See the note on --b5r-deal-a at the top of this file. */ animation-range-start: var(--b5r-deal-a); animation-range-end: var(--b5r-deal-b); } /* Two pages facing each other is five leaves, not nine. layout() writes .is-spread / .is-single on the mount on every single pass — never behind a comparison with the previous state — so this can be trusted to follow a resize across the 840px line. */ .bk.bk-scene.is-spread { animation-name: b5r-deal-5; } /* ======================================================================== 4. HOW THE LEAVES ARE DEALT ACROSS THE TRAVEL Not a straight ramp. Each leaf gets a slice of the travel, and inside its slice it RESTS for the first quarter, turns over the middle half, and rests again for the last quarter. Two consequences, and both are the reason for it: - Half of the whole travel is a settled page. A reader who stops scrolling — and a seventy-year-old on a phone stops often — is far more likely to be looking at a page lying flat than at a leaf standing on its edge. - The plateaus are centerd exactly on t/N of the timeline, so book.js can send Back and Next to a scroll offset and land on a resting page with one line of arithmetic instead of inverting an easing curve. A leaf therefore turns in 50% of its slice. MEASURED at 390x844 that is about 59px of scroll for a turn — a page going over under the thumb, not a slider being dragged. ======================================================================== */ /* Nine leaves: the cover, then eight sheets. (k + 0.25)/9 still rests at k/9; (k + 0.75)/9 has arrived at (k+1)/9. */ @keyframes b5r-deal-9 { 0.0000% { --bk-p: 0 } 8.6667% { --bk-p: 0.057778 } 9.7778% { --bk-p: 0.111111 } 11.1111% { --bk-p: 0.111111 } 19.7778% { --bk-p: 0.168889 } 20.8889% { --bk-p: 0.222222 } 22.2222% { --bk-p: 0.222222 } 30.8889% { --bk-p: 0.28 } 32.0000% { --bk-p: 0.333333 } 33.3333% { --bk-p: 0.333333 } 42.0000% { --bk-p: 0.391111 } 43.1111% { --bk-p: 0.444444 } 44.4444% { --bk-p: 0.444444 } 53.1111% { --bk-p: 0.502222 } 54.2222% { --bk-p: 0.555556 } 55.5556% { --bk-p: 0.555556 } 64.2222% { --bk-p: 0.613333 } 65.3333% { --bk-p: 0.666667 } 66.6667% { --bk-p: 0.666667 } 75.3333% { --bk-p: 0.724444 } 76.4444% { --bk-p: 0.777778 } 77.7778% { --bk-p: 0.777778 } 86.4444% { --bk-p: 0.835556 } 87.5556% { --bk-p: 0.888889 } 88.8889% { --bk-p: 0.888889 } 97.5556% { --bk-p: 0.946667 } 98.6667% { --bk-p: 1 } 100.0000% { --bk-p: 1 } } /* Five leaves, above 840, where two pages face each other. */ @keyframes b5r-deal-5 { 0.0000% { --bk-p: 0 } 17.0000% { --bk-p: 0.2 } 20.0000% { --bk-p: 0.2 } 37.0000% { --bk-p: 0.4 } 40.0000% { --bk-p: 0.4 } 57.0000% { --bk-p: 0.6 } 60.0000% { --bk-p: 0.6 } 77.0000% { --bk-p: 0.8 } 80.0000% { --bk-p: 0.8 } 97.0000% { --bk-p: 1 } 100.0000% { --bk-p: 1 } } /* ======================================================================== 5. THE PANEL THE WIDE "OPEN THE BOOK" ROW GOES, AND ONLY INSIDE THE SCENE. It is 68px of a screen the pin has to fit the whole object into, and in the scene it names an act the scroll has already performed. The act is not lost: chrome() names the two buttons that remain "Next: open the book" and "Back: close the book", which is what a screen reader has always heard from them at those two states. Outside the scene the row is exactly where it was. The magnifier row forauthors.js inserts after it is NOT touched. It is the one control on this site aimed squarely at a reader who cannot read small type; it anchors itself to .bk-open-row, which still exists and is only not painted, and it stays in the stack. ======================================================================== */ .bk.bk-scene > .bk-open-row { display: none; } /* On a phone the chrome is still three stacked rows, and every pixel of it is a pixel the pin cannot use, so the two gaps come in one step each. The caption keeps its own min-height, which is what stops the object jumping when a caption goes from one line to two. Stopped at 839px, one below finish.css §11G's 52.5rem: above that the controls are that file's one bar, its margins are that file's business, and this file has no reason to be inside them. */ @media (max-width: 52.4375rem) { .bk.bk-scene > .bk-caption { margin-top: var(--s3); } .bk.bk-scene > .bk-controls { margin-top: var(--s2); } } /* ======================================================================== 6. WHAT THIS FILE DELIBERATELY DOES NOT DO COMPOSE THE PANEL. There was a two-column layout here — the book on the left, the caption and the controls in a 20rem column beside it — written against the measurement that at 1280 the widest inked element was 584px in a 1280 viewport. It has been withdrawn, and the withdrawal is the point: finish.css §11G already lays the plate's controls out as ONE bar above 840 ("one bar, not three stacked"), and press.css §11H puts the mount in a 44rem track beside the reading column at 1280. That is the same job, done by the file that owns the composition, and two files arranging one panel is how a panel ends up arranged twice. What was lost by withdrawing it is nothing the reader sees: the height that layout stood to save is saved anyway, by the control bar that file already builds, and this file's pin measures whatever the panel comes to rather than assuming it. What was gained is that the scene now works on top of any composition of the panel instead of only on the one it was written against — which matters, because that composition changed twice while this was being written. THE ONE THING IT STILL TAKES is the wide "Open the book" row, and only because on a phone that row is still a row of its own — 68px of a band the pinned panel has to fit the whole object into. ======================================================================== */ } }