/* * pm-contact — the contact page (WO-38, frame 90:4211). * * Compiled to assets/css/components/contact.css by src/build-tokens.mjs, * which substitutes the breakpoint markers (a comment holding `@bp `) * with the pixel value from tokens/tokens.json. Custom properties cannot * resolve inside @media conditions and a bare integer is invalid CSS, so the * build appends the unit. Never type a breakpoint width here. * * Every colour is a --pm-color-* token; spacing, type sizes, leading and * tracking come from tokens/tokens.json. No hex value and no literal * breakpoint width may appear in this file. Values the token file does not * hold (the 612px panel, the 80px header term, the 40px nav-inset term) are * typed with a comment citing the extract key they come from — the same * technique as the button's 14px label and the header's 80px bar. * * The full-bleed technique is the header's own (header.css): the scaffold * body constrains content to a centred 72rem column with --pm-space-8 * padding; the section escapes that box horizontally. */ .pm-contact { position: relative; box-sizing: border-box; /* * WO-99 AC 13 — `clip`, and `hidden` must not come back. * * Both clip the same rectangle (the padding box; `overflow-clip-margin` * defaults to zero), so the photo and the scrim are contained exactly as * before. The difference is invisible until something animates: * `overflow: hidden` makes this element a SCROLL CONTAINER, `overflow: * clip` does not. A `view()` timeline resolves against its subject's * nearest ancestor scroll container, and reveal.js's SELECTOR_MAP stamps * `[data-pm-reveal]` on blocks INSIDE this one — so with `hidden` their * timeline resolved against this element, which never scrolls, froze at a * fixed progress, and the reveal simply never ran. Measured before the * fix: 108 frozen instances across nine pages and four viewports, stuck * between 0.91 and 1.0 progress. Visible, and never animating. * * If you are here because a block does not animate: this is the thing to * check first, on this element and on every ancestor of the block. */ overflow: clip; width: 100vw; margin-inline: calc(50% - 50vw); /* * 38-contact.json#measured.layout.padding — 24 top / 96 sides / 96 * bottom. The top term carries the overlay header band, so the panels' * top edge lands at the frame's y 144: 80 (the built header's height, * header.css) + 40 + 24 (this frame's own top padding) = 144. The 80 * and 40 are typed; 24 is --pm-space-6. * * WO-93 — the 40 here is the RESERVATION: the band the overlay header's * own inset occupies (header.css's `top: 40px` on * body.pm-header--overlay .pm-header, * 93-contact-spacing.json#measured.header_block.padding_top). It is NOT * a duplicate of that inset and it does not come out: delete it and the * content row moves from 144 to 104, which is AC 1's second half * (counter-review objection 9). Two numbers, two jobs, one page. */ padding: calc(80px + 40px + var(--pm-space-6)) var(--pm-space-24) var(--pm-space-24); font-family: var(--pm-font-family-base), system-ui, sans-serif; } /* * WO-38 — under the overlay header the bar is out of flow (header.css), so * the scaffold body's --pm-space-8 padding-top would show above the photo. * The section pulls itself up by that same token with the header's own * technique (header.css's margin-top), so it — not the scaffold padding — * starts at y 0. The homepage's in-flow negative header never matches this * rule and stays untouched. */ body.pm-header--overlay .pm-contact { margin-top: calc(-1 * var(--pm-space-8)); } /* * The background layer: cover, behind the header and both panels, * decorative (alt="", WO-38 AC 2). The two-class selector beats Elementor's * `.elementor img { height: auto; max-width: 100% }` (MISTAKES.md §C15). * * WO-93 — element-agnostic: the layer is an when only a poster/still * is set and a