went #FFAC66 -> #1a2328 on hover
(a stray inherited link colour changing under a label that could not),
so the button had a computed hover and NO VISIBLE one. The resting value
is unchanged — `--myk-btn-fg` is set to `--mk-ink-body` on the scope. */
color: inherit;
white-space: nowrap;
}
/* ==========================================================================
PART B — RETARGETING SALIENT
==========================================================================
Everything below exists to sit Salient's real `mouse_follow_image` post grid
on Figma's geometry. Nothing below changes the mechanic; the rAF follower,
the cross-fade, the counter-scale reveal and the blend-mode title ghost are
all still driven by the vendored element-post-grid CSS and init.js.
Each block names the Salient declaration it displaces and its specificity,
so the next person can see the fight rather than re-run it.
§7. TRACK GEOMETRY — Salient's flex grid becomes Figma's 3 x 72 / 48
====================================================================== */
/* The grid box is the full 1040 content width. */
.mk-amenities52__gridwrap {
align-self: stretch;
}
/* Displaces, in order:
`.nectar-post-grid{display:flex;flex-wrap:wrap}` (0,1,0)
`@media(min-width:1000px) .nectar-post-grid-wrap[data-style=
mouse_follow_image] .nectar-post-grid[data-columns="3"]
{margin:0 -50px}` (0,4,0)
The -50px bleed plus 50px item padding is Salient's 100px gutter; Figma's is
72 with no bleed. Selector below is (0,5,0) so it wins in both media states.
`align-items: start` is counterAxisAlignItems: MIN — spec §2.1 is explicit
that shorter cells DO NOT stretch (EN row 3 has a 72-tall Starlink cell
top-aligned in a 108-tall row).
R17-01 — row-gap 48 -> 24, HER CALL, NOT THE SPEC'S. `row-gap: 48px` above
was spec §2.1's own Figma-derived number for the ORIGINAL nine-item grid
and was exactly right for that grid. Her round-17 words are about the
47-item grid this became in round 16: "it's quite spaced out... this list
is quite long... tighten up the vertical spacing... occupy a little less
space" — a live judgment call on a much longer list, not a correction to
the original nine-row spec, so this is a deliberate founder-directed
deviation (same category as R10-06/R11-08/R13-01 elsewhere in this file),
not a bug fix. 24, not an arbitrary smaller number: `--mk-space-24` is
tokens.css's own "THE dominant stack gap" (tokens.css:249) — the value
already used for stack rhythm throughout this page — so tightening reuses
an established constant instead of inventing one. Halves the row-gap
without touching column-gap (72, untouched — R17-01 is "vertical spacing"
only) or any type size. The var() carries a literal fallback per this
file's own §"THE BREATH" convention (below, `--mk-breath`). */
.mk-amenities52 .nectar-post-grid-wrap[data-style="mouse_follow_image"] .nectar-post-grid[data-columns="3"] {
display: grid;
grid-template-columns: repeat(3, 1fr);
column-gap: 72px; /* spec §2.1 — derived from child x, UNCHANGED */
row-gap: var(--mk-space-24, 24px); /* R17-01 — was 48px (spec §2.1); tightened, her call */
align-items: start;
margin: 0;
}
/* Displaces every width/padding Salient puts on the cell:
`.nectar-post-grid-item{width:100%}` (0,1,0)
`@media(min-width:1000px) ...[data-columns="3"] .nectar-post-grid-item
{padding:0 50px}` (0,4,0)
`@media(max-width:999px)and(min-width:691px) ...[data-columns="3"]
[data-grid-spacing=none] .nectar-post-grid-item{width:50%}` (0,5,0)
`@media(max-width:690px) body .nectar-post-grid[data-columns]
[data-grid-spacing] .nectar-post-grid-item{width:100%;
padding-bottom:75%}` (0,3,1)
The last one is the dangerous one: `padding-bottom:75%` is Salient's aspect
box for a card grid and would give every amenity row a 224px tail.
Selector below is (0,6,1) — above all four. */
body .mk-amenities52 .nectar-post-grid-wrap[data-style="mouse_follow_image"] .nectar-post-grid[data-columns="3"] .nectar-post-grid-item {
width: auto;
min-width: 0;
padding: 0;
}
/* Salient makes `.inner` an absolutely-positioned 100%/100% card face with a
10% black wash and clips it:
`.nectar-post-grid-item .inner{overflow:hidden;position:relative;
width:100%;height:100%;position:absolute;top:0;left:0;
background-color:rgba(0,0,0,.1)}` (0,2,0)
The `mouse_follow_image` sheet already undoes most of that, but only inside
`@media (min-width:1000px)`. Restated unconditionally, and carried to (0,6,0)
rather than the (0,3,0) the shorter selector would give, so it also clears
`...[data-style=mouse_follow_image] .inner{overflow:visible;width:auto}`
(0,3,0) on cascade order rather than on a tie. `overflow: visible` is
mandatory: the follower is a descendant and must escape. */
.mk-amenities52 .nectar-post-grid-wrap[data-style="mouse_follow_image"] .nectar-post-grid .nectar-post-grid-item .inner {
position: static;
overflow: visible;
width: auto;
height: auto;
background-color: transparent;
}
/* `.content` is the `Icon and text ` frame: HORIZONTAL, itemSpacing 4,
counterAxisAlignItems MIN (spec §2.4).
THE PADDING HERE IS THE ONE THAT BITES. Three Salient rules set it and they
are NOT all low-specificity:
`.nectar-post-grid .nectar-post-grid-item .content{padding:35px}` (0,3,0)
`.nectar-post-grid-wrap:not([data-style=content_overlaid])
.nectar-post-grid .nectar-post-grid-item .content{padding:25px 0}` (0,5,0)
<- `:not()` contributes its argument's specificity, and our wrap has
`data-style="mouse_follow_image"`, so this DOES match. It would add
25 top + 25 bottom to every amenity row and take the 40px rows to 90.
`.nectar-post-grid .nectar-post-grid-item .content
{position:absolute;width:100%;z-index:200}` (0,3,0)
The `mouse_follow_image` `position:static` fix is gated behind
`min-width:1000px`, so it is restated here unconditionally.
`data-mouse_follow_post_spacing` is absent from the markup precisely so the
`{padding:45px 0}` variant never matches — see the HTML header.
Selector below is (0,6,0), above all three.
No z-index is set — `z-index:200` would put the label above the follower. */
.mk-amenities52 .nectar-post-grid-wrap[data-style="mouse_follow_image"] .nectar-post-grid .nectar-post-grid-item .content {
position: static;
display: flex;
align-items: flex-start; /* icon top-aligned to the label */
gap: 4px; /* itemSpacing 4 */
width: 100%;
padding: 0;
z-index: auto;
}
/* Label box = cell 298.67 - icon 40 - gap 4 = 254.67 (spec §2.4b).
Displaces `.nectar-post-grid-wrap:not([data-style=content_overlaid])
.content .item-main{width:100%}` (0,4,0),
which as a flex item would be 100% of the CELL and overflow by 44px.
Selector below is (0,5,0).
`pointer-events:none` from Salient's base rule was PREVIOUSLY kept here on
the theory that it is what lets the pointer fall through the text to
`.nectar-post-grid-item`, which is where `:hover` lives now that
`a.nectar-post-grid-link` has been dropped. R19-01 found that theory is
what actually BREAKS the hover live (founder-confirmed the mix-blend title
overlay + follower photo were not appearing — reproduced, not assumed,
with a real trusted pointer via review/regression/cdp.py, not a synthetic
dispatch):
R11's entrance-reveal (§8b below) rests `.post-heading`/
`.mk-amenities52__icon` at `translate: 0 40px` — 40px BELOW their
settled position — until the section's own reveal wave finishes (up to
~1.5s+ after entering view for this section's LAST-firing column, which
is exactly where "Bathtub" — the founder's own example — sits: nth-
child(3n+3), §8d above). A short, 1-line row's own box is exactly
`--myk-mv-travel` (40px) tall (confirmed live:
`.nectar-post-grid-item` computes `height:40px` for a 1-line label), so
while still resting, the label paints EXACTLY at/below that box's own
bottom edge — outside it. Hit-testing there, with the label itself
`pointer-events:none`, falls through PAST `.nectar-post-grid-item`
entirely to whatever is physically behind that pixel instead — no
element in this component's own subtree, so `:hover` never reaches it.
Confirmed live: `item.matches(':hover')` reads `false` the instant the
cursor arrives on the (visible, still-rising) label, and STAYS `false`
even ~1.5s later once the label has fully risen into place — the
browser does not retroactively re-run hit-testing under a STATIONARY
cursor merely because a CSS transform animated the paint underneath it.
A single hover-and-hold — exactly how someone checks "does hover
work" — permanently misses.
FIX: give the label normal hit-testing back, so it is itself hoverable
wherever it actually paints, transform-shifted mid-reveal or not —
`:hover` still cascades to every DOM ancestor of whatever element is
actually hit, regardless of that hit element's visual box relative to the
ancestor, so `.nectar-post-grid-item:hover` (and everything keyed to it:
the follower photo, §9's title-overlay ghost) fires correctly through the
whole reveal, not only after it settles. There is no link under the label
any more for a restored pointer to "miss" (the reason pass-through
existed in the first place), and `.content` itself carries no
pointer-events override of its own (Salient sets it only on
`.item-main`), so nothing else in the hover chain is touched by this. */
.mk-amenities52 .nectar-post-grid-wrap .nectar-post-grid-item .content .item-main {
flex: 1 1 auto;
width: auto;
min-width: 0;
display: block;
pointer-events: auto;
}
/* ==========================================================================
§8. THE LABEL — `post-heading` retargeted to Poppins 20/36
====================================================================== */
/* Poppins Regular 400 / 20, lineHeight PERCENT 179.99999523162842 = exactly
36px, letterSpacing 0, fill #1a2328 (spec §4). Pinned in px, not 1.8, to
remove rounding drift (spec §2.4).
Three sheets fight for this element:
`body h3{font-family:Cormorant;font-size:38px;line-height:42px;
font-weight:500;letter-spacing:-0.03em}` (0,0,2)
<- the RESORT demo's dynamic stylesheet, vendored with the shell
`.mk-page :is(h1,h2,h3,.mk-serif){font-family:var(--mk-font-serif);
font-optical-sizing:none;font-variation-settings:"wdth" 100,"opsz" 18}`
(0,1,1)
<- tokens.css. Correct for the Merriweather headings, wrong here.
`.nectar-post-grid-wrap[data-style=mouse_follow_image]
.nectar-post-grid-item .content .post-heading{line-height:1.5em}` (0,4,0)
<- would give 30px, not 36.
`@media(min-width:1400px) ... .content .post-heading{max-width:85%}` (0,4,0)
<- would clamp the label to 216 and re-wrap it at 1440.
Selector below is (0,5,0) and beats all four.
`position: relative` is load-bearing, not cosmetic — see §9.
The optical-size / variation reset undoes the Merriweather pin from
tokens.css; Poppins is a static face and would otherwise carry a stale
`font-variation-settings`.
LINE BREAKS VERIFIED, not assumed. Greedy wrapping computed from
Poppins-Regular.ttf (hmtx, upem 1000) at 20px in the 254.67 label box
reproduces Figma's line counts for all nine labels, and the break points
match the @2x export word for word:
Full kitchen 110.70 1 line
Free washer in unit 186.90 1
Free dryer in unit 165.98 1
AC split, ductless system 246.34 1 (8.3 to spare)
Dedicated workspace 218.16 1
Bathtub 79.46 1
Starlink wifi with battery 235.90 / backup power 143.72 2
Free parking on 154.66 / premises, paved road 218.30 /
and driveway 135.88 3
Shared salt water, infinity 250.12 / pool outdoor - open all
230.76 / year 44.64 3
Two are tight: "AC split, ductless system" clears the box by 8.33px and
"Shared salt water, infinity" by 4.55px. Both hold with the shipped face —
but they are the first things to break if the Poppins source is ever swapped
or if a `letter-spacing` leaks onto this element. Row heights follow from the
line counts: 40 / 40 / 108 (spec §2.1, total 40+48+40+48+108 = 284). */
/* ==========================================================================
R10-06 — CARD LABELS FADE BUT DO NOT TRAVEL: root cause + fix
--------------------------------------------------------------------------
Her words: all nine amenity rows ("full kitchen, free washer in unit, free
dryer in unit, and the rest") "only fade in" — no translate-up, unlike the
page's standard fade+move-up grammar. Every row already carries
`data-mv="body"` (R8-13, `sections/16-amenities-52.html`) and R8-13's own
testing confirmed `.post-heading` computed `translate: none / transform:
none` at rest, i.e. `translate` was free for the shared vocabulary to use --
correct, at the time, and still true today (`translate` is not the bug).
THE ACTUAL BUG, MEASURED (review/r10/r10-amenities-offers/header-before.json,
fresh headless Chrome, all 5 widths, SHA served == disk): computed
`transitionProperty` on every `.post-heading` reads
"transform, opacity, color" — NOT "opacity, translate"
at duration "0.45s, 0.45s, 0.45s" / delay "0s, 0s, 0s" — Salient's own
numbers (element-post-grid.q-98228494a0.css:
`.nectar-post-grid .nectar-post-grid-item .content .post-heading{
transition:transform .45s cubic-bezier(.15,.75,.5,1),opacity .45s
cubic-bezier(.15,.75,.5,1),color .45s cubic-bezier(.15,.75,.5,1)}`,
specificity (0,4,0)). That vendor rule is what the browser resolves the
`transition` PROPERTY from, because nothing in this file's own §8 selector
below — despite winning every other declaration on this element at
(0,6,0) — ever declared `transition` itself, so there was nothing to
contest that one property with. `[data-mv]`'s own start/rest values (`html.mv
[data-mv]{translate:0 var(--myk-mv-travel)}` / `.mv-in{translate:0 0}`,
myk-motion.css) still WIN the `translate` VALUE at every moment — the
number genuinely changes from 40px to 0 on reveal — but `translate` is
absent from the winning `transition-property` LIST, so that value change is
never interpolated: it snaps in one frame, invisibly, while `opacity` (which
IS in Salient's list, just at 0.45s/no-delay rather than the vocabulary's
0.2s/no-delay BODY numbers) visibly fades over time. A snap-then-fade reads
exactly as "only fades in, no translate" — because the translate genuinely
is not animating, even though the value is correct at both ends.
FIX: extend THIS rule's own `transition` — the one already winning every
other property here — to also cover `translate`, using the page's own BODY
role tokens (`--myk-mv-dur-body` 200ms / `--myk-mv-delay-body` 0ms /
`--myk-ease-entrance`) so the added travel matches every other BODY-role
element on the page. Salient's own transform/opacity/color entries are kept
VERBATIM — they still drive the hover colour-swap and the vendor's own
subtext transforms elsewhere in this component; nothing about hover
behaviour changes. `translate` is simply the fourth item this element was
always supposed to transition and never did. */
.mk-amenities52 .nectar-post-grid-wrap[data-style="mouse_follow_image"] .nectar-post-grid-item .content .post-heading {
position: relative;
margin: 0;
max-width: 100%;
font-family: var(--mk-font-sans);
font-weight: var(--mk-w-regular);
font-size: var(--mk-size-body); /* 20 */
line-height: 36px; /* 180% of 20, exactly */
letter-spacing: 0;
text-transform: none;
color: var(--mk-ink-body);
font-optical-sizing: auto;
font-variation-settings: normal;
/* R10-06 — adds `translate` to Salient's own transition-property list
(transform/color kept verbatim: transform still drives the vendor's own
hover subtext-slide, color still drives the hover swap — hover is
untouched by any of this).
R11-08 (2026-08-22) — her words: "same speed, same timing, copy and
paste that [hero] approach." `opacity` and `translate` were on the page's
generic BODY tokens (0.45s Salient / 200ms `--myk-mv-dur-body`) — REPLACED
here with the literal values read off sections/00-hero.css's own
`mykHeroRise` keyframe (700ms, `cubic-bezier(.4, 0, .2, 1)`), not
approximated. `color` genuinely never changes on this element (confirmed:
no `.post-heading` — as opposed to `.post-heading:before`, the separate
blend-mode ghost — rule in element-post-grid.q-98228494a0.css ever sets
`opacity` on hover), so widening opacity's own duration cannot touch any
hover behaviour; same reasoning R10-06 already used for `translate`. */
transition:
transform .45s cubic-bezier(.15,.75,.5,1),
opacity 700ms cubic-bezier(.4, 0, .2, 1),
color .45s cubic-bezier(.15,.75,.5,1),
translate 700ms cubic-bezier(.4, 0, .2, 1);
}
/* ==========================================================================
R11-06 / R11-07 / R11-08 / R11-09 / R11-10 — THE AMENITIES WAVE
--------------------------------------------------------------------------
R11-06, WHICH CASE (determined live before any of the below was written,
full receipt in founder-trace/helix/R11-06-07-08-09-10.md): a realistic
wheel-driven drive (review/r11/r11-amenities-wave/drive-before-*.json,
`build/v1-en/_tools/r11-amenities52-drive-probe.py`, her own 1750x980
first) confirmed R10-05's header stagger and R10-06's label travel are
BOTH still genuinely working, byte-identical to round 10's own verified
numbers — this is not a regression and not a stale-page misread of a fix
that already works. It IS a genuine residual gap in what was never built:
(1) the nine rows had no deterministic wave, only incidental IO-timing
gaps (measured 67-142ms apart depending on width/scroll speed — not an
authored, verifiable overlap); (2) each row's own motion ran on the 200ms
BODY token, four times faster than hero's 700ms, which reads as a "quick
pop" rather than a fade a human eye can track — literally her words,
"animating them up really quickly, not fading in"; (3) the icons and the
"See all 47 amenities" button had ZERO animation, confirmed live
(opacity:1/translate:0 for the entire drive, every width) — two of the
picture's moving parts were simply always-on. All three are now fixed
together, below, because they are one mechanism.
§8a. THE TRIGGER, NEUTRALISED — R10-11's exact technique
(founder-trace/helix/R10-10-11-12.md §2): `.mk-amenities52__gridwrap`
carries the ONE real `data-mv="body"` in this subtree (16-amenities-52.html
R11-07), so the shared engine's IntersectionObserver watches exactly one
element and adds `.mv-in` to it once, off the grid's OWN scroll geometry —
MEASURED close to where the old first-row trigger fired (within ~40-135px
of scroll across all 5 widths, review/r11/r11-amenities-wave/geometry.json)
so this is not a worse-positioned trigger, just a single deterministic one.
Its own opacity/translate output is neutralised — nothing about the WRAP
itself is meant to be seen moving; only its `.mv-in` STATE is used, to
drive every row below via CSS. `(1,2,1)` (this section's id) outranks
myk-motion.css's own `html.mv [data-mv]` START state `(0,2,1)` and its
`.mv-in` END state `(0,3,1)` outright — an id beats any class count. */
#s16-amenities-52 .mk-amenities52__gridwrap[data-mv] {
opacity: 1;
translate: none;
transition: none;
}
/* §8b. REST STATE — icons + labels, hidden under `html.mv` same as every
other adopted element (Guard A fail-open, myk-motion.css §2), but keyed off
the CLASS SELECTOR rather than `[data-mv]`: R11-07 deliberately removed
`data-mv="body"` from all nine `.post-heading` rows (16-amenities-52.html),
so the shared engine's generic `html.mv [data-mv]` rule no longer reaches
them — this section now owns their rest state directly, same specificity
shape, same fail-open guarantee (reduced motion / no-JS -> `html.mv` never
lands -> this rule never applies -> opacity:1/translate:none, the default).
`40px` is `var(--myk-mv-travel)`'s CURRENT value, read and pinned literally
per R11-08's "don't approximate" discipline — same number, written the way
hero's own rule writes it. */
html.mv #s16-amenities-52 .mk-amenities52__icon,
html.mv #s16-amenities-52 .post-heading {
opacity: 0;
translate: 0 40px;
}
/* §8c. THE ICON'S OWN TRAVEL — R11-10. Confirmed live before writing this
(review/r11/r11-amenities-wave/drive-before-*.json): `.mk-amenities52__icon`
carried zero `data-mv`, zero transition, opacity 1 / translate none for the
entire drive at every width — genuinely never animated, not merely missed
by R10-06's text-only fix (R10-06 only ever touched `.post-heading`). No
`transform`/`translate` is set anywhere else on this element (§4 above), so
the travel is free — same `travelProp()` check the JS runs before hand-
authoring, done here by hand since this element is hand-adopted, not
selector-adopted. Same literal hero numbers as §8 above, same reasoning. */
#s16-amenities-52 .mk-amenities52__icon {
transition:
opacity 700ms cubic-bezier(.4, 0, .2, 1),
translate 700ms cubic-bezier(.4, 0, .2, 1);
}
/* §8d. THE WAVE, R11-07/R11-08 — SUPERSEDED BY R12-05, collapsed to ONE
BEAT. R11-07/08 gave the nine rows nine independent fixed delays (base
100ms, step 120ms, copied literally from hero's 4-line ladder) — this
worked exactly as measured (R11 verify: every consecutive pair genuinely
overlapping, all 5 widths) but her round-12 report persisted anyway:
"still too fast... timing doesn't feel right," alongside her own explicit
offered alternative: "it would even be okay with me if you animate in the
whole list as one set... I see you did a whole grid there, that would be
fine too."
ROOT CAUSE, MEASURED, not assumed a second time (R12-04's own
instruction): hero's 120ms step suits FOUR short lines of a headline: it
is not a per-element defect, it is a translation mismatch — spreading the
SAME hero-copied step across NINE small, visually similar list rows
compounds into a long (100ms -> 1060ms, 960ms end-to-end before the CTA
even starts) tightly-packed cascade where any one row's own 700ms motion
is 83%-overlapped by its neighbour's (700-120=580ms of simultaneous
motion) — objectively hard to consciously track as nine distinct beats,
which is the literal shape of "I can't actually catch how nice all the
animations are." Retuning the STEP alone does not fix this: a wider step
under the same nine-item shape either still compresses (fast) or pushes
the total wave past 2+ seconds (a fresh regression, "why is this section
slower to finish than every other one"), and would need re-tuning again
the next time a tenth amenity is added — a structural problem, not a
number to nudge.
FIX — her own offered alternative, taken because it is structurally
correct, not merely permitted: every icon + label across all nine rows
now shares ONE `transition-delay`, so the whole grid fades and rises
together as a SINGLE beat — this section's third beat (see the R12-02/04
comment above `.mk-amenities52__heading[data-mv]`), landing 350ms (half
of the shared 700ms duration) after the heading's own beat starts, the
same repeating half-duration cadence as every other beat in this section.
`:nth-child` is removed entirely — one rule instead of nine, and it no
longer needs editing if a tenth amenity is ever added (self-maintaining,
"more reliable" per this round's own framing of the choice). Icon and
label of a row still share the identical delay, unchanged from R11-07's
own reasoning ("a button label belongs to the button" logic extended to
"an icon and its label belong to the same beat").
---------------------------------------------------------------------------
R13-01 — SUPERSEDED AGAIN. One beat was structurally right (self-
maintaining, no per-row hand-editing) but threw away information her R13
report specifically named: "it's still loading in in a very strange
order where some of the things at the bottom load in before things at
the top." A single uniform delay across all nine rows cannot itself
cause a top/bottom ordering complaint — every row fires on the SAME
clock tick — so this was never really about the grid beat's internal
order; it was the residual complaint from BEFORE R12-05's collapse,
re-read against the DOM. Verified against the real markup (this file,
grep for `.nectar-post-grid-item`, all 9 confirmed direct children of
`.nectar-post-grid` in this exact order, no interleaved siblings to
perturb `:nth-child` arithmetic):
1 Full kitchen 2 Free washer 3 Free dryer
4 AC split 5 Workspace 6 Bathtub
7 Starlink 8 Free parking 9 Salt water pool
Read as the 3x3 grid it renders as (`data-columns="3"`), that DOM order
is ROW-MAJOR — but her named groups ("kitchen, AC split, and Starlink...
free washer, dedicated workspace, and free parking... free dryer,
bathtub, and shared salt water infinity pool") are exactly the grid's
three COLUMNS: col 1 = items 1/4/7, col 2 = items 2/5/8, col 3 = items
3/6/9 (`founder-trace/FT-20260822-jehnean-round13.md`'s own DOM-order
table, re-verified live here rather than re-trusted). R12-05's single
beat was already order-safe in isolation (nothing could read as
"backwards" when everything fires at once) but gave up the clean
left-to-right column sweep she is asking for now that she has named it
explicitly — this is a MORE PRECISE instruction superseding R12-05's
collapse for the ordering question specifically, not a reversal of its
"don't hand-edit nine rows" reasoning (still true: three `:nth-child`
rules, not nine).
FIX — three rules, one per column, keyed by `:nth-child(3n+1|+2|+3)` on
`.nectar-post-grid-item` (the direct parent the nth-child count is taken
against, not the icon/label descendants themselves): each column's own
three items (icon + label, both) still share ONE identical delay so a
column reads as a single simultaneous unit exactly as her words describe
("as one set") — the fix R12-05 already made for "share the identical
delay within a row" is unchanged, just re-scoped from all nine rows to
three at a time. Columns step 120ms apart — not a new number: the exact
hero-derived per-item step R11-08 already established for this section
(comment table above `.mk-amenities52__heading[data-mv]`: hero's own
120ms/700ms = 17.1% ratio). R12-04's regression (this same 120ms step,
applied nine times, compounded into an 83%-overlapped 960ms cascade) does
not reapply here: three steps of 120ms is 240ms of total spread, not
R11-08's 960ms — the problem R12 fixed was the STEP COUNT (nine), not the
step size, and nine is gone for good (three grouped beats, not three
times as many rows). Column 1 keeps the exact base value R12-05 shipped
(`+700ms` off the LEAD delay, i.e. this section's third macro-beat,
still 350ms after the heading's own beat per R12-04's cadence) so this
diff is additive — two new delay values, nothing already-correct
disturbed. `.mk-amenities52__cta` (§8e) is UNCHANGED: its literal 1150ms
already lands 110ms after column 3's new 1040ms start — later than every
column, still comfortably inside column 3's own 700ms travel, so "then
the CTA after those things" already held without touching that number;
confirmed live, not assumed, in the verify pass below. */
#s16-amenities-52 .mk-amenities52__gridwrap[data-mv].mv-in .nectar-post-grid-item:nth-child(3n+1) .mk-amenities52__icon,
#s16-amenities-52 .mk-amenities52__gridwrap[data-mv].mv-in .nectar-post-grid-item:nth-child(3n+1) .post-heading {
/* COLUMN 1 — Full kitchen (1) / AC split (4) / Starlink (7). Unchanged
base: this section's third macro-beat, 350ms after the heading.
R19-FIX — `translate: 0 0` -> `translate: none`. VERIFIED live by
r19:verify:amenities (fresh Fable verifier): a settled, non-`none`
translate value (even one that computes to a visual no-op offset) opens
a NEW STACKING CONTEXT on this element, which traps §9/§9b's
`z-index:1000` title/icon overlay ghosts inside it — they can then never
compete with the hover-follower photo's `z-index:100` in the correct
stacking layer, so both ghosts render zero pixels on hover despite every
computed property (opacity, mix-blend-mode, z-index, fill) reading
correct. `translate: none` is the identical visual rest position (no
stacking context is not a position change) and interpolates the same as
an explicit `0 0` endpoint for the CSS transition already running on
this element (`translate` animates from/to `none` as zero, per the CSS
Transforms spec) — so the reveal motion itself is unaffected; only the
settled END state stops creating a stacking context. */
opacity: 1; translate: none; transition-delay: calc(var(--myk-mv-delay-lead) + 700ms);
}
#s16-amenities-52 .mk-amenities52__gridwrap[data-mv].mv-in .nectar-post-grid-item:nth-child(3n+2) .mk-amenities52__icon,
#s16-amenities-52 .mk-amenities52__gridwrap[data-mv].mv-in .nectar-post-grid-item:nth-child(3n+2) .post-heading {
/* COLUMN 2 — Free washer (2) / Dedicated workspace (5) / Free parking
(8). +120ms off column 1 — hero's own established per-item step.
R19-FIX — `translate: none`, same reasoning as column 1 above. */
opacity: 1; translate: none; transition-delay: calc(var(--myk-mv-delay-lead) + 700ms + 120ms);
}
#s16-amenities-52 .mk-amenities52__gridwrap[data-mv].mv-in .nectar-post-grid-item:nth-child(3n+3) .mk-amenities52__icon,
#s16-amenities-52 .mk-amenities52__gridwrap[data-mv].mv-in .nectar-post-grid-item:nth-child(3n+3) .post-heading {
/* COLUMN 3 — Free dryer (3) / Bathtub (6) / Shared salt water pool (9).
+240ms off column 1, i.e. +120ms off column 2 — same repeating step.
R19-FIX — `translate: none`, same reasoning as column 1 above. */
opacity: 1; translate: none; transition-delay: calc(var(--myk-mv-delay-lead) + 700ms + 240ms);
}
/* §8e. THE BUTTON — R11-09, sequenced LAST, the fourth beat of this
section's now-uniform 350ms/50%-of-700ms cadence (R12-02/04/05 comment
above `.mk-amenities52__heading[data-mv]`): 1150ms, i.e. 350ms after the
grid beat (§8d) starts, not R11-09's original 1180ms (that number was
"one more 120ms hero-step past row 9's 1060ms," which no longer exists as
a concept now that the grid is one beat rather than nine). "See all 47
amenities" is a sibling of the gridwrap (both direct children of
`.mk-amenities52__col` — confirmed live, the two elements' opening/closing
``s balance between them), reached with a general sibling combinator
off the SAME one trigger — the exact shape R10-11 used for the footer's
newsletter heading (`~`, off `.mk-footer__links`'s `.mv-in`). Full
rest-state + transition + reveal live with the button's own rule in §5
below, not here, so this section's CTA styling stays in one place. */
/* ==========================================================================
§9. THE BLEND-MODE TITLE GHOST — the part that makes the effect read
====================================================================== */
/* Salient paints a white duplicate of the label over the photo with
`mix-blend-mode: overlay` so the label survives wherever the image passes
behind it (nonprofit.lift.md §1d). Everything about it is inherited
verbatim from the vendored sheet — `content: attr(data-title-text)`, the
`mix-blend-mode`, `z-index:1000`, the white fill from
`[data-text-color=dark][data-post-title-overlay=yes]`, and the
`opacity 0 -> 1` on `:hover`. Two things had to change:
(a) ANCHORING. `.post-heading::before` is `position:absolute; left:0; top:0`
and resolves against the nearest positioned ancestor. Salient's own
layout has the heading at the item's top-left so `.nectar-post-grid-item
{position:relative}` is good enough. Ours starts 44px in, after the
icon, so the ghost would sit 44px left of the label it is meant to
cover. Fixed with `position: relative` on `.post-heading` in §8 — which
is Salient's own remedy for its centred-text variant:
`.col.center ...[data-post-title-overlay=yes] .nectar-post-grid-item
.post-heading{display:inline-block;position:relative}`
(b) WIDTH. Salient ships `max-width:70%` on the ghost. Its own titles are
one or two lines, so the mis-wrap barely shows. Ours run to three lines
("Free parking on premises, paved road and driveway"), and at 70% the
ghost re-wraps to four or five and hangs below the real label. Set to
100% so the ghost registers exactly. THIS IS A DELIBERATE DEVIATION FROM
THE REFERENCE — it is listed in the lossiness returned with this
section, not hidden here.
Salient's rule is (0,5,1); the selector below is (0,6,1). */
.mk-amenities52 .nectar-post-grid-wrap[data-style="mouse_follow_image"] [data-post-title-overlay="yes"] .nectar-post-grid-item .post-heading:before {
max-width: 100%;
width: 100%;
}
/* ==========================================================================
§9b. THE ICON'S OWN GHOST — R19-02, new work extending §9's pattern
====================================================================== */
/* R19-02: "extend the SAME technique... to each item's ICON, not just its
heading." §9's ghost is `content: attr(data-title-text)` because its
payload is text — a pseudo-element can generate text from an attribute,
but it cannot generate an SVG glyph (`content` has no vector-graphics
form). The icon is an inline `