/* ============================================================================ myk-pacing.css — FOUNDER ITEM G. THE WHOLE PAGE, RETIMED TO THE OMAI CURVE. ---------------------------------------------------------------------------- Lane `r4:pacing-apply`. Founder item G of founder-trace/FT-20260819-jehnean-review.md, plus the media half of A10. Her words: "It's all just a little bit slower, a little bit more open… more relaxed animations that allow a little more time to set up." `css/myk-motion.css` (lane `r3:motion-vocab`) already put 43 previously-STATIC elements onto the measured Omai clock. It could not reach the page's ORIGINAL entrance systems, because those are Salient's and they were never static — they were running, at the wrong curve. This file is that second half. --------------------------------------------------------------------------- THE ONE NUMBER THIS FILE EXISTS TO CHANGE --------------------------------------------------------------------------- review/omai/PACING.md §7.2, measured on omaivillas.com and re-derived here from the live computed styles (review/pacing/verify-before.json): percentage of the total travel already spent at one TENTH of the animation Omai cubic-bezier(.4, 0, .2, 1) 2.6 % ours cubic-bezier(.25, 1, .5, 1) 34.7 % <- 13x The first tenth is the part the eye locks onto, and "a little more time to set up" IS that ramp. `easeOutQuart` has no ramp at all: its velocity is MAXIMUM at t=0 and only ever decreases. `cubic-bezier(.4, 0, .2, 1)` is symmetric in-out — it starts at zero velocity, peaks at t≈0.30, and lands soft. One curve, everywhere, is the whole fix. --------------------------------------------------------------------------- WHERE THIS FILE DEPARTS FROM PACING.md §8.2, AND WHY — READ BEFORE "FIXING" --------------------------------------------------------------------------- §8.2 row 1 prescribes, for the split heading: **700 ms, travel a flat 40px**. THIS FILE DELIBERATELY TAKES NEITHER, and both refusals are measured. 1 · THE TRAVEL CANNOT BE FLATTENED. It is not a style choice, it is the mechanism. `.nectar-split-heading … > * > span` is `overflow: hidden` with a line box of `line-height: 1.2`, and `.inner` is parked at `translateY(1.3em)` — i.e. one tenth of an em BELOW the bottom of its own mask. That is what makes it a REVEAL. Park it at a flat 40px instead and, on the 96px headings this page ships, the glyph starts 40px down inside a ~115px mask: 65 % of the letterform is already on screen at rest, and the "reveal" becomes a nudge of visible text. The 1.3em is structural. 2 · 700 ms WOULD MAKE THE PAGE FASTER, WHICH IS THE OPPOSITE OF THE REQUEST. §8.2 was derived when these headings measured 20 / 24 / 48 px (PACING §6). They no longer do — lane `r3:vertical-rhythm` grew the type, and the live measurement now reads 48 / 60 / 96 / 108 px, so 1.3em is 62 - 140 px, not 26 - 62 px. Peak velocity is `maxSlope(curve) x travel / duration`: maxSlope cubic-bezier(.25, 1, .5, 1) = 4.000 (at t = 0) maxSlope cubic-bezier(.4, 0, .2, 1) = 2.735 (at t = 0.302) 96px heading, travel 124.8px today 1200ms easeOutQuart -> 416 px/s ramp: 34.7 % at t=10 % §8.2 700ms Omai curve -> 488 px/s FASTER. rejected. HERE 1200ms Omai curve -> 284 px/s ramp: 2.6 % at t=10 % Normalised to type size, so the comparison survives a future type change: Omai's heading is 48px with 40px of travel over 700ms = 3.26 em/s peak. Ours at 1.3em/1200ms with their curve is 2.96 em/s = 0.91x Omai — just under the reference, which is what "a little bit slower" asks for. At 700ms it would be 5.08 em/s = 1.56x Omai. SO THE RULE THIS FILE FOLLOWS IS: **CHANGE THE CURVE, KEEP THE CLOCK.** Every travel distance on this page is larger than Omai's flat 40px, because our type is larger. Shortening the durations to their literal millisecond values therefore RAISES peak velocity past the reference. The invariant worth holding from the reference is the RAMP and the PEAK, not the number of milliseconds — and holding the clock also means this pass changes exactly one variable, so what the founder sees is attributable. --------------------------------------------------------------------------- WHAT IS NOT HERE --------------------------------------------------------------------------- · No `wheel` listener, no `scroll-snap-type`, nowhere. REQ-SCROLL-01. Proven per run: review/pacing/verify-*.json `wheel.ratio` must read 0.0. · No smooth-scroll layer. The Lenis decision and the file-verified evidence behind it are in js/myk-pacing.js §0. · No new easing token. `--myk-ease-entrance` is declared by css/myk-motion.css and only DEFAULTED here, so the two files cannot drift apart. ========================================================================== */ :root { /* Defaulted, not redefined: css/myk-motion.css §tokens declares `--myk-ease-entrance: cubic-bezier(.4, 0, .2, 1)` and is linked BEFORE this file, so this line never wins. It exists so that this stylesheet still does the right thing if it is ever loaded on a page without the vocabulary. */ --myk-pace-ease: var(--myk-ease-entrance, cubic-bezier(.4, 0, .2, 1)); /* THE CLOCK IS HELD, NOT SHORTENED — see the header. These are tokens rather than literals so that "a little bit slower still" is a one-line change and not an archaeology exercise. Each carries the value it is replacing. */ --myk-pace-heading-dur: 1200ms; /* was 1200ms, salient-elements.css:58 */ --myk-pace-heading-delay: 100ms; /* was 0 — Omai's own lead delay, and the literal reading of "a little more time to set up": nothing moves for 100ms. */ --myk-pace-column-dur: 1500ms; /* was 1500ms, sections/00-hero.css:628 */ --myk-pace-btn-dur: 300ms; /* was 300ms, css/myk-btn.css */ } /* ========================================================================== §1 · THE SPLIT HEADING — 25 elements, the loudest motion on the page -------------------------------------------------------------------------- MEASURED BEFORE (review/pacing/verify-before.json, `systems`): transform/opacity/filter 1200ms delay 0 cubic-bezier(0.25, 1, 0.5, 1) travel 1.3em at font-size 48 / 60 / 96 / 108px = 62.4 / 78 / 124.8 / 140.4px peak 208 / 260 / 416 / 468 px/s first tenth: 34.7 % of the travel AFTER: identical selector, identical duration, identical travel. Curve and delay only. peak 142 / 178 / 284 / 320 px/s first tenth: 2.6 % of the travel THE SELECTOR IS COPIED VERBATIM from css/salient-elements.css:58 — `[data-stagger="true"]:not([data-text-effect*="letter-reveal"])` and all — for a reason that is not tidiness. That file is a LIFT: its own header says "NOT OURS: see the file header before editing anything in it." Matching its selector exactly, from a later file, means (a) this override lands on exactly the set that rule lands on and no other, and (b) if the vendored rule is ever re-lifted and its selector changes, this override stops matching and the heading visibly returns to the old curve — a loud failure instead of a silent partial one. `html.mv` adds (0,1,1) on top, so this wins on specificity and does not depend on link order alone. `filter` IS KEPT IN THE LIST. Salient transitions it for the letter-reveal- blur effects. Our headings do not use those, so it never fires — but dropping it from the list would silently change behaviour for any future heading that does, and this file has no business making that decision. GATED ON `html.mv`. That class is added by js/myk-motion.js from , and it is absent under `prefers-reduced-motion` and absent if JS never runs. So under reduced motion this whole section evaporates and Salient's own rule — which css/reduced-motion.css already neutralises — is what remains. This file can never be the reason motion appears for a reader who asked for none. ========================================================================== */ html.mv .nectar-split-heading[data-animation-type="line-reveal-by-space"][data-stagger="true"]:not([data-text-effect*="letter-reveal"]) span .inner { transition: transform var(--myk-pace-heading-dur) var(--myk-pace-ease) var(--myk-pace-heading-delay), opacity var(--myk-pace-heading-dur) var(--myk-pace-ease) var(--myk-pace-heading-delay), filter var(--myk-pace-heading-dur) var(--myk-pace-ease) var(--myk-pace-heading-delay); } /* ========================================================================== §2 · THE HERO COLUMN SEQUENCE — curve only, delays and duration untouched -------------------------------------------------------------------------- The hero is in the founder's own WHAT-LANDED list ("Hero nav/text/logo animate in"), so the bar for touching it is high and this is the narrowest possible change: ONE property. sections/00-hero.css:626-631 drives four columns with CSS @keyframes rather than Salient's JS, because the page still ships `` (REQ-HERO-3, open) and a CSS animation is immune to the no-js opacity guard: .mk-hero .wpb_column.has-animation[data-animation] { animation-duration: 1500ms; animation-timing-function: cubic-bezier(0.25, 1, 0.5, 1); <- (0,3,1) animation-fill-mode: both; } Overriding ONLY `animation-timing-function` from here at (0,4,1) leaves `animation-name`, `animation-duration`, `animation-fill-mode` and the whole 0 / 300 / 500 / 600 ms `data-delay` stagger exactly where that file put them. Nothing about WHAT the hero does changes; only the shape of the 75px it already travels. travel 75px, 1500ms: peak 200 px/s -> 137 px/s, first tenth 34.7 % -> 2.6 % A CSS animation is also why this has to be `animation-timing-function` and not `transition-timing-function`: `mk-hero-fade-in-from-bottom` is a keyframe animation and transitions do not apply to it. Writing the transition property here would be a no-op that LOOKS like a fix, which is worse than no fix. TO REVERT: delete this block. One rule, no side effects. ========================================================================== */ html.mv .mk-hero .wpb_column.has-animation[data-animation] { animation-timing-function: var(--myk-pace-ease); } /* ========================================================================== §3 · THE BUTTONS — one easing token across the site -------------------------------------------------------------------------- PACING §8.2, last row but one: `300ms ease` -> `300ms var(--myk-ease-entrance)`. MEASURED BEFORE: 16 `.myk-btn` computing `color 300ms ease`. `ease` is `cubic-bezier(.25, .1, .25, 1)` and reads differently from the entrance curve — 9.5 % travelled at t=10 % against 2.6 %. `transition-timing-function` ONLY. The property list and the duration stay with css/myk-btn.css, which owns the component; this file has no opinion on WHICH properties a button transitions. THE FLIP IS NOT EXCLUDED, AND THE FIRST DRAFT OF THIS FILE EXCLUDED IT. The reasoning for excluding it was sound — PACING §8.2 leaves the fancy box alone because "it is a hover, not an entrance", a hover wants a fast head, and css/myk-btn.css §8 establishes .55s cubic-bezier(.25,1,.33,1) as this page's one hover curve. The reasoning was just aimed at the wrong element. Read out of css/myk-btn.css:984 and :995, the flip's transition is declared on `.myk-btn--flip .nectar-text-reveal-button__text` and its `::after` — a DESCENDANT — and never on `.myk-btn` itself. `transition-timing-function` set here therefore cannot reach the flip at all; all it reaches is the button's own `color, box-shadow, outline-color` 300ms transition. Excluding `.myk-btn--flip` bought nothing and cost consistency: it left the six flip buttons changing colour on a different curve from the ten that do not. The hover curve is untouched either way. WHAT THIS RULE REACHES, MEASURED: 12 of the page's 17 `.myk-btn`. The other five are the header's, and they are excluded ON PURPOSE rather than by accident — stated here because a rule that silently misses a third of its population is the kind of thing that gets "fixed" later by someone raising specificity until the number reads 17. · `#header-outer` (5 buttons). Salient's own header sheet reaches them through an ID, so its declarations outrank anything this file can write without an ID of its own. It is also the boundary js/myk-motion.js draws first in its SKIP list — "the nav flip + logo, LANDED and named by the founder" — and reaching across it from a pacing file to restyle a component another lane owns is how a founder-praised thing regresses. The header buttons keep `300ms ease`. · `.mk-newsletter__btn` (1 button) computes `450ms cubic-bezier(.25,1,.33,1)` — the `--myk-flip-*` hover pair, a deliberate component choice in css/myk-btn.css, not a stale default. Left alone for the same reason the fancy box is. ========================================================================== */ html.mv .myk-btn { transition-timing-function: var(--myk-pace-ease); } /* ========================================================================== §4 · A10 · MEDIA — the start state for the elements js/myk-pacing.js adopts -------------------------------------------------------------------------- Founder A10, verbatim: *"Images fade in as their section arrives — what- makes-unique background, the parallax one, and the recovery-plan 1-5 imagery. Take a little more time to get into that section."* THE ROLE ALREADY EXISTS. css/myk-motion.css §1 declares `html.mv [data-mv="media"]` as opacity-only, 1000ms, 100ms delay, entrance curve — Omai's `data-animate-img`, which transitions `opacity` alone and never translates an image (PACING §2 table). Its own header says the role is "DECLARED BUT NOT ADOPTED BY THIS LANE… so that lane can opt an element in with one attribute and inherit this file's easing and clock instead of inventing a second vocabulary." This file takes that offer. There is no second vocabulary: js/myk-pacing.js sets `data-mv="media"`, and every value comes from myk-motion.css. MEASURED BEFORE (review/pacing/media-before.json — a REST-state census of every element ≥200x200 that paints an ``, a `