/** * @file * Hover-lift atom (Phase 6.4) — `css/atoms/hover-lift.css` * * EN: Reusable card-hover-interaction primitive. Owns ONLY the interaction * behaviour: smooth `transition`, `:hover` `translateY` lift, and * `:hover` box-shadow elevation swap. NO visual shape (background, * radius, base shadow) — that's the surface atom's job * (`.dck-surface`). Compose them by stacking classes on the same * element: `
`. * * DE: Wiederverwendbares Karten-Hover-Interaktions-Primitiv. Definiert * AUSSCHLIESSLICH das Interaktionsverhalten: weicher `transition`, * `:hover`-`translateY`-Lift und `:hover`-Box-Shadow-Elevation. * KEINE visuelle Form (Hintergrund, Radius, Basisschatten) — das ist * Aufgabe des Surface-Atoms (`.dck-surface`). Komposition durch * Stapeln auf demselben Element. * * Audit findings driving extraction (see scripts/reports/phase-6.4-…): * - `.basic-card:hover` basic-card.css:53-57 (-4px, shadow-soft → shadow-lg, 0.4s cubic-bezier) * - `.side-image-card:hover` side-image-card.css:60-64 (-4px, shadow-soft → shadow-lg, 0.4s cubic-bezier) * - `.side-image-card-bordered:hover` side-image-card.css:77-82 (-4px, none → bordered-hover shadow) * - `.masonry-item:hover` masonry-grid.css:54-58 (-3px, shadow-soft → shadow-lg, 0.4s cubic-bezier) * → NORMALISED to -4px in Phase 6.4 * - `.card-accordion:hover` card-accordion.css:58-61 (-3px, hardcoded shadows, 0.3s ease) * → NORMALISED to -4px + 0.4s cubic-bezier in Phase 6.4 * - `.case-dossier:hover` case-study-dossier.css:76-80 (NO lift, hero base → hero hover) * → composed via --shadow-only + --shadow-hero modifiers * - `.case-dossier .case-dossier-logo` lifts independently on parent hover. * That parent-→-child compound pattern stays in case-study-dossier.css * (atoms cover single-element hover; multi-element compound hovers * stay component-local but use the same token vocabulary). * - `.topics-grid-card-inner` topics-grid.css (Phase 6.4 NEW affordance: -4px, --shadow-soft via surface → --shadow-lg) * * Modifiers (compose with `.dck-hover-lift` on the consumer element): * --shadow-hover-bordered — `--hvl-shadow-hover: var(--card-shadow-hover-bordered)` * (heavier hover shadow for `.dck-surface--no-shadow` * variants — bordered side-image-card) * --shadow-hero — `--hvl-shadow-hover: var(--card-shadow-hero-hover)` * (hero-size hover shadow, pairs with `.dck-surface--shadow-hero` * — case-dossier parent) * --shadow-only — `--hvl-lift-y: 0` * (cancels the translateY lift while preserving the shadow * swap — used by case-dossier parent which deliberately * does NOT translate on hover; its child .case-dossier-logo * translates independently via component-local compound rule) * * Modifiers are mutually composable. Example: case-dossier parent gets * `.dck-hover-lift .dck-hover-lift--shadow-only .dck-hover-lift--shadow-hero` * — no lift, hero hover shadow, smooth transition. * * Interaction-only contract (mirrors Phase 6.2/6.3 atom rules): * The atom's BASE selector (`.dck-hover-lift`) declares NO visual * shape — no background, no border-radius, no base box-shadow, no * overflow, no padding, no position. Only `transition`. The BASE * defines the transition channel; the `:hover` selector defines * the active interaction (transform + box-shadow swap). * * Composition expectation: the host element MUST already be a * visual surface (have a background and ideally a base shadow) * before `.dck-hover-lift` is applied. Without a base shadow, * the hover state will appear as a shadow-from-nothing flash — * the surface atom (`.dck-surface`) is the canonical companion. * In practice every Phase 6.4 consumer either has its own * pre-existing shape declaration (legacy class CSS) AND/OR * composes `.dck-surface` alongside `.dck-hover-lift`. * * Library wiring: declared as its own `hover_lift` library in * `upmarkit_theme.libraries.yml` under `css.component:` (NOT * `css.theme:` — Phase 6.2 regression precedent). Added as a * dependency of every card consumer library that composes it: * basic_card, side_image_card, masonry_grid, card_accordion, * case_study_dossier, topics_grid. * * Token-only: every consumed value reads through `var(--…)`: * - transition: `var(--card-transition)` (Schema §13) * - lift: `var(--card-lift-y)` (Schema §13) * - shadow: `var(--card-shadow-hover)` (default), `--card-shadow-hover-bordered`, `--card-shadow-hero-hover` (Schema §13) * The atom does NOT hardcode any value. Atom-internal `--hvl-*` vars * provide the override surface for modifiers and for consumer fine- * tuning at the consumer's own selector. * * Class binding sites (humans writing classes into Twig templates): *
*
*
*
*
*
*
*/ .dck-hover-lift { /* Atom-internal interaction primitives — modifiers mutate these vars; consumers may override them on their own selector for fine-grained cases. Defaults pull straight from the Schema §13 tokens. */ --hvl-lift-y: var(--card-lift-y); --hvl-shadow-hover: var(--card-shadow-hover); transition: var(--card-transition); } .dck-hover-lift:hover { transform: translateY(var(--hvl-lift-y)); box-shadow: var(--hvl-shadow-hover); } /* ============================================================================ MODIFIERS — mutate atom-internal vars only. No direct property overrides. Composable: a consumer may stack multiple modifiers (e.g. case-dossier parent uses both `--shadow-only` and `--shadow-hero`). ============================================================================ */ .dck-hover-lift--shadow-hover-bordered { --hvl-shadow-hover: var(--card-shadow-hover-bordered); } .dck-hover-lift--shadow-hero { --hvl-shadow-hover: var(--card-shadow-hero-hover); } .dck-hover-lift--shadow-only { /* Cancel the lift. The :hover rule still fires `transform: translateY(0)` which is a visual no-op vs no transform, but the transition declaration on the BASE still animates the box-shadow swap smoothly. Used by .case-dossier (parent shadow-only, child .case-dossier-logo lifts via component-local compound rule). */ --hvl-lift-y: 0px; } .dck-hover-lift--none { /* Phase 6.4 Step 2a — Reusable "no hover affordance" modifier. Cancels BOTH the lift AND the shadow swap on hover. Use when a card-shaped surface must LOOK like a card but offer zero interactive affordance (e.g. .side-image-card-full — a full- width layout-breakout variant where lifting would falsely suggest clickability and the parent ancestor may carry a cursor: pointer that needs neutralising on this surface). Mechanism: - --hvl-lift-y: 0 → translateY(0) on :hover is a no-op vs no transform. - --hvl-shadow-hover: var(--surf-shadow, none) → if .dck-surface is composed on the same element, the hover shadow matches the surface's BASE shadow (no swap). If not, falls back to `none`. - cursor: default on :hover → defeats any cursor: pointer inherited from an ancestor. (If the consumer has no ancestor with cursor: pointer, this is a no-op — safe everywhere.) Composes with any surface modifier (--no-shadow, --shadow-hero, etc). Designed to be reusable across consumers, not specific to one. */ --hvl-lift-y: 0px; --hvl-shadow-hover: var(--surf-shadow, none); } .dck-hover-lift--none:hover { cursor: default; } /* ============================================================================ LEGACY CLASS ALIASES — placeholder section. No legacy aliases needed for Phase 6.4. The consumer-side classes (`.basic-card`, `.side-image-card`, `.masonry-item`, `.card-accordion`, `.case-dossier`, `.topics-grid-card-inner`) retain their original :hover rules during the per-consumer migration steps (3–9 of Phase 6.4); at each migration step the :hover block is REMOVED from the component CSS file and `.dck-hover-lift` is ADDED to the DOM element instead. The atom takes ownership of the interaction once the component-local :hover block is gone. When/if those legacy class names are themselves deprecated in a later phase (post-content-migration), this block becomes the alias surface for them. Until then it intentionally stays empty. ============================================================================ */