/** * DFS Motion — Hover Grow for Elementor Columns. * * @decision D410 — the columns sit in line at their own height; hovering one * grows it vertically PAST that band, and the page does not move. * * Chris, via Brad: "the columns are all normal in line but when one is hovered * it grows vertically ... also has a slight dropshadow around the hovered * column". Brad, on the version that shrank them instead: "when i turn on hover * grow it still just makes section short and grows it back to 100 it never * extends". * * --------------------------------------------------------------------------- * HOW IT WORKS * * on hover, the card takes NEGATIVE block margins * * A stretched flex item is sized to the line MINUS its margins, so negative * margins make it taller by exactly that much — while its contribution back to * the column's height (height + margins) is unchanged. The card grows and * overflows its column; nothing in the layout moves. * * The column keeps its own height at rest. Nothing is shrunk, and no height is * ever typed. * * THE RESERVE GOES ON THE CONTAINER, NOT THE COLUMN. That padding is written by * the Grow By control (see the PHP), because the room has to exist INSIDE the * clipping box — see the next section. It is a one-time cost paid at load. * * --------------------------------------------------------------------------- * WHY THE RESERVE CANNOT GO ON THE COLUMN — MEASURED ON THE REAL PAGE * * The first working version put `padding-block` on the column itself. On a test * row where EVERY column had the feature, that raised the row and behaved. On * Brad's actual row, where ONE column has it, it did the opposite: * * column padding 30/30 applied, column 552, card 492, row 552 * * The column is a STRETCH flex item, so its height is the line's height, not * its content's. Padding on one stretched item does not push the line up — it * just eats that item's own content box. So the card shrank by 60 and "grew * back to 100" on hover, which is exactly what Brad saw. * * MEASURED with the reserve moved to the container instead: * * row column card clipped page * as shipped (column) 552 552 492 no 4646 * container, at rest 586 526 526 no 4680 * container, hovered 586 526 586 NO 4680 * * Card at full height at rest, grows by exactly 60, row and page stable. * * --------------------------------------------------------------------------- * THE CLIPPING TRAP — WHY A RESERVE IS NEEDED AT ALL * * Negative margins alone are enough to grow the card, and on an ordinary row * that is the whole job. MEASURED on Brad's row, though: * * .elementor-container overflow: auto hidden overflow-y: hidden * * That row is a `dfs-hscroll` horizontal scroller, and overflow clips at the * PADDING box. Without the reserve the card grows 30px above and below and is * cut off on both edges — the effect runs perfectly and is invisible. With the * reserve, the grown card lands exactly on the padding box (measured: card top * 780 == clip top 780, card bottom 1366 == clip bottom 1366) and survives. * * --------------------------------------------------------------------------- * THE DISCARD PILE — every model was driven on the live page, not reasoned about * * A. animate the card's height * row 122 -> 140, page 2048 -> 2066. REJECTED: the page shifts. * * B. min-height reserve + clip-path window * Worked, shipped in 4.39.0. REJECTED: min-height cannot be "the column's * natural height", so it forced a typed Card Height field. * * C. padding reserve on the column + margins animated on hover * Shipped in 4.40.0 and WRONG on a real row — see above. The proof that * passed had the class on all five columns, which is not how it is used. * * D. padding + PERMANENT negative margins + clip-path * MEASURED: reserve 0, card visible 42px instead of 122. Padding and * margin cancel exactly, so nothing is reserved and the card shrinks. * * E. container reserve + margins animated on hover <- THIS * * E animates margin, a layout property, which the gsap-core skill rightly warns * about. Both composite-only candidates were measured and neither can reserve * space: clip-path only ever reveals what is already inside an element's box, so * it cannot grow anything past its own footprint. The layout triggered here is * confined to one column's subtree, and row and page were measured unchanged. * * --------------------------------------------------------------------------- * EVERY VALUE HAS A FLOOR (@decision D407). If Elementor's post CSS is cleared, * the container reserve goes with it and the growth still runs off this file — * it degrades to "may be clipped inside a scroller", never to "broken". */ /* * THE CLASS IS REPEATED THREE TIMES ON PURPOSE. Do not "tidy" it. * * Elementor's column Border/Background hover-transition control writes a * `transition` SHORTHAND to the very same element, from post CSS: * * .elementor-4800 .elementor-element.elementor-element-34317310 > .elementor-element-populated * { transition: background 0.3s, border 0.3s, border-radius 0.3s, box-shadow 0.3s } * * That is (0,4,0) and it beat this rule at (0,2,0). Because it is a SHORTHAND it * also resets transition-property to its own four entries — none of which is * margin — so the growth applied instantly. MEASURED on the live page: * * computed transition-property = "background, border, border-radius, box-shadow" * * which is exactly the snap Brad reported: "it just like snaps to grow". * * Repeating the opt-in class takes this to (0,4,0) plus the element selector and * wins without !important, which would be the wrong tool — it would silently * kill an author's own transitions on that column. * * Elementor's four properties are RESTATED here so raising specificity does not * cost them. 0.3s is Elementor's own default; an author who changed it loses * that customisation on hover-grow columns only, which is the smallest price * available and is why it is written down rather than hidden. MEASURED after the * fix: transition-property = "margin-top, margin-bottom, background, border, * border-radius, box-shadow", durations "0.5s, 0.5s, 0.3s, 0.3s, 0.3s, 0.3s". */ /* * AN INNER SECTION MUST FILL THE COLUMN. * * Brad, with a video-background inner section in column 3: "theoretically would * take up 100% of column height but i think the column specific padding youre * adding limits the inner section". * * MEASURED — the padding is innocent. The column has padding 0, and removing the * container reserve entirely changed the column height by 0px at both 30px and * 110px of reserve; the container absorbs it by growing. * * The real cause is Elementor's own wrap: * * .elementor-widget-wrap display:flex flex-wrap:wrap align-content:flex-start * * With flex-wrap:wrap, align-items stretches an item within its LINE, but * align-content:flex-start packs the single line to the top and sizes it to the * item's own height. So the inner section sat at its intrinsic 437 inside a 537 * column and never stretched. MEASURED with align-content:stretch: 437 -> 537, * exactly filling the column, with the other four columns, the row and the page * all unchanged. */ .elementor-column.dfs-hg--yes > .elementor-widget-wrap { align-content: stretch; } /* * AND THE BACKGROUND VIDEO INSIDE IT MUST RE-FIT. * * Elementor's background-video script sizes the