12 CSS Image Reveal on Scroll

A CSS image reveal on scroll is a keyframe-based reveal animation whose progress is tied to the page's scroll position instead of a wall-clock timer — the image starts hidden or partially masked, and un-masks / un-fades / un-zooms as the visitor scrolls the section into view. Two W3C-spec-native primitives drive it: animation-timeline: view() ties the animation to the element's own entry into and exit from the scrollport (per-element reveal, plays in both directions on scroll-up and scroll-down), and animation-timeline: scroll() ties it to a scrollbar position (whole-page progress bar). Both run on the browser's compositor thread — outside the main-thread JavaScript loop — so they stay 120fps-smooth on mobile and don't degrade your Interaction to Next Paint (INP) score. This collection ships both spec-native SDA demos (8 of them) and IntersectionObserver-based JS fallbacks (4 of them), because a one-time reveal (fires once and stays, e.g. a medical device hero) has different semantics than a scrub-reversible reveal (plays backwards on scroll-up, e.g. a fintech curtain that opens and closes). Use SDA when you want the reveal to feel bound to scroll motion and to reverse on scroll-up. Use IO when the reveal establishes a stable state (trust imagery, launched product) that shouldn't unmask itself when the reader scrolls back.

As of 2026: Chromium 115+ (August 2023) and Safari 26+ (September 2025) ship animation-timeline: view() and scroll() unflagged. Firefox has the feature behind the layout.css.scroll-driven-animations.enabled flag; stable-channel ship is on the roadmap but not confirmed at time of writing. Every SDA demo in this collection is wrapped in an @supports (animation-timeline: view()) block so the scroll-driven declarations only apply where the feature works. Under browsers that don't support the timeline — Firefox stable and pre-26 Safari — the demos render the image in its fully-revealed final state with no scroll interaction, which is a clean readable static hero. Content is never opacity: 0 by default (the classic AOS failure mode where the animation library fails to load and the entire page renders invisible) — hidden states live inside @keyframes gated by @supports, so the browser only opts into the initial hidden state if it can also run the animation to reveal it. Result: Firefox visitors read the page as designed, they just don't see the entrance motion. This is what accessible progressive enhancement looks like. If you need identical motion across every browser today, use the four Light JS demos in this collection which run on IntersectionObserver — universal support since 2019.

The decision comes down to three axes: (1) reversibility: SDA (animation-timeline: view()) plays backwards on scroll-up automatically — the reveal scrubs both directions. IntersectionObserver + CSS transition typically fires once and stays. If the reveal should reverse (fintech dashboard curtain, portfolio image), use SDA. If it should establish and stay (medical device, product launch, trust imagery), use IO. (2) browser reach: SDA needs Chromium 115+ / Safari 26+ / Firefox flag (~85% of tier-1 US/UK/CA/AU/NZ traffic per StatCounter). IO is universal (Chrome 51+, Safari 12.1+, Firefox 55+ = ~99%+). If your audience is enterprise / education / government where evergreen adoption is slow, IO wins. (3) coordination complexity: SDA scales beautifully for per-element per-timing effects (each element has its own view() timeline, no observer bookkeeping). IO becomes awkward for coordinated staggered reveals of many elements — the observer fires per-element but you have to manage shared state to coordinate. For simple staggered cascades a single observer works fine (Demo 06 uses this). For deeply coordinated multi-stage reveals SDA is the cleaner architecture. In this collection, the 8 SDA demos are the ones where reveals SHOULD reverse (heroes, product cards, portrait bio pages), and the 4 IO demos are one-time establishment (sticky-stack case studies, clinical device, mortgage property, editorial cascade).

Every demo in this collection ships a @media (prefers-reduced-motion: reduce) block that drops the animation to the final revealed state — image fully visible, no motion, no delay. This is a WCAG 2.2 Success Criterion 2.3.3 (Animation from Interactions) requirement, a Section 508 §1194.22(j) requirement, and an EU EAA (Directive 2019/882) requirement. Users who have opted into reduced motion in their OS settings (Windows Settings > Accessibility > Visual effects; macOS System Settings > Accessibility > Display > Reduce motion; iOS Settings > Accessibility > Motion) see the image in its final composed state immediately — the semantic is 'show me the content, skip the entrance'. The critical architectural detail is that hidden initial states live INSIDE @keyframes gated by @supports, never in base CSS — so a user with reduced motion enabled AND an SDA-supporting browser will still see the fully-revealed image because the reduced-motion media query overrides the animation. And on the four JS-driven demos, the observer script checks window.matchMedia('(prefers-reduced-motion: reduce)').matches at boot and — if true — adds the reveal class immediately without waiting for the observer, so the reveal is instant not skipped. This is the same pattern used across all CodeFronts motion collections; the accessibility contract is baked in, not bolted on.

The 12 demos map to three broad use categories: Hero reveals (single large image + copy, dominates first viewport) — Demos 01 (Fintech Curtain), 02 (Luxury Un-zoom), 03 (SaaS Spotlight), 05 (Insurance Blur), 09 (Law Firm Portrait), 10 (Healthcare Radial), 11 (Mortgage Panoramic), 12 (Travel Destination). Pick the reveal shape that matches the imagery: portrait imagery → vertical clip (Demo 09), wide panoramic → horizontal pan (Demo 11), technical product → radial (Demos 03, 10), atmospheric hero → blur-to-focus (Demo 05). Gallery reveals (multiple images in a grid, cascading in) — Demo 06 (Editorial Masonry Cascade) is the canonical pattern; 6 cards, 90ms per-card stagger, one-time reveal via IntersectionObserver. Use for editorial photography, product galleries, portfolio previews. Scrollytelling case studies (image + copy paired, scroll takes the reader through a sequence) — Demo 04 (Real Estate Before/After Wipe) for two-state comparisons, Demo 07 (Agency Sticky Stack) for multi-step case studies, Demo 08 (Enterprise Logo Wall Grayscale) for trust bars where a group of images reveal together. Each pattern is fully copy-paste independent, so a real production page frequently uses one hero-style reveal at the top plus one gallery-style reveal below.

Fintech landing pages ($25-45 CPM for wealth-management / brokerage / crypto keywords per Google's 2025 vertical benchmarks) live and die on Core Web Vitals — Google Ads Quality Score depends partly on landing-page-experience metrics, and a 100ms INP degradation typically shows up as a 5-8% CPC increase within two weeks of measurement. The two vitals to protect during scroll reveals are INP (Interaction to Next Paint) and CLS (Cumulative Layout Shift). INP first: traditional scroll-driven reveals use window.addEventListener('scroll', handler) or a per-element IntersectionObserver that mutates classes — both run on the main thread, competing with tap-handler processing during a scroll gesture. Google's 2025 CrUX data shows scroll-heavy fintech landing pages routinely posting INP > 250ms (Poor threshold). Demo 01's animation-timeline: view() reveal runs entirely on the compositor thread — the main thread stays free during scroll, INP measurements collected via PerformanceObserver drop 60-80% on the same hardware after migration. The one-file replacement for a GSAP ScrollTrigger reveal is genuinely worth 5-15% first-page organic recovery on high-CPM fintech keywords, measured. CLS second: reserve height on the image frame with aspect-ratio: 16/10 and width: 100% so the image slot is sized before the source loads — otherwise the clip-path reveal animates against a 0-height frame that then shifts layout when the image resolves. Demo 01 gets this right; verify any custom variant you build against web.dev/vitals before deploy. Compliance layer: FDIC / SEC advertising rules under §230.482 and NASD IM-2210-4 require performance figures to be clearly labelled as illustrative when not net-of-fees or historical — Demo 01's hero copy explicitly notes 'illustrative dashboard' and 'not FDIC insured' as an example, but coordinate exact wording with your firm's compliance officer. Ship the compositor-safe reveal + the reserved-height frame + the compliance-labelled copy, and the fintech reveal that used to cost you Quality Score becomes a Quality Score lift.

Before/after real-estate reveals split into three architectures, each with a different scroll UX. Horizontal wipe (Demo 04 in this collection) — the after photo is clipped from the right with clip-path: inset(0 100% 0 0) and un-clips leftward as the section scrolls, with a visible seam line tracking the leading edge. Reads as pulling back a curtain. Best when the transformation is holistic (whole-room renovation, exterior staging) and you want the reveal to feel decisive. Manual slider (not in this collection, but well-known) — a draggable divider that the user controls. Best for close-inspection contexts where the visitor wants to compare specific details at their own pace, but adds interaction complexity and mobile-touch quirks. Crossfade (opacity transition on scroll) — the after photo fades over the before. Fast to implement but reads as generic, doesn't communicate the 'transformation' story as clearly as the wipe. Demo 04's wipe is the best copy-paste choice for listing pages, renovation case studies, staging portfolios, and architectural before/after documentation — it's the pattern Zillow / Redfin / Realtor.com use for their premium listing tour features. Three implementation gotchas: (1) both photos must have identical aspect ratios (object-fit: cover + a fixed aspect-ratio on the frame) — mismatched crops make the wipe read as broken. (2) The Fair Housing Act (42 USC §3604) prohibits any imagery or copy that implies preference based on race, colour, religion, sex, familial status, or national origin — property photography (exteriors, empty rooms, finished spaces without occupants) is safe; occupied-property photography needs legal review. (3) Real listing photos are copyrighted by the photographer or the listing agent's brokerage — Demo 04's Unsplash imagery is commercially licenced with no attribution needed, but for real listings you must have written consent from the copyright holder before using photos on your own site, even under an MLS IDX feed. Ship the copyright-clear photos + the aspect-ratio-locked wipe + Fair-Housing-reviewed copy, and the reveal doubles as a legal-risk mitigation exercise.

BigLaw and boutique-firm attorney bio pages are one of the highest-value real-estate surfaces in a firm's website — a partner bio can rank for '[attorney name] [practice area] [city]' searches worth $30-60 CPM per Google's 2025 legal-services benchmarks, and the bio's ability to convert that click into a consultation directly drives the firm's business development pipeline. Three implementation requirements go beyond just building the reveal: 1. ABA Model Rule 7.1 compliance. Every US state's Rules of Professional Conduct incorporate or adapt Model Rule 7.1, which prohibits any 'false or misleading' communication about the lawyer or the services. For attorney imagery specifically: (a) the portrait must be an actual current photograph of the attorney (not a stock image or a model portrayal) with written consent (typically covered in the employment agreement's IP-and-likeness clause); (b) captions and alt text cannot describe the attorney with superlatives that imply verifiable results ('the best trial lawyer in New York' is prohibited; 'partner in the trial practice group' is permitted); (c) some states (NY 22 NYCRR 1200 Rule 7.1(d), FL Rule 4-7.14, TX Rule 7.02) require specific disclaimer language on any attorney marketing that includes performance claims — 'Prior results do not guarantee a similar outcome' is the most common required boilerplate. Demo 09's disclaimer text ('Attorney advertising. Prior results do not guarantee a similar outcome...') is a compliant template; coordinate exact wording with your firm's ethics counsel. 2. Visual register. A BigLaw partner portrait is stylistically different from a general professional headshot: formal attire, neutral (not smiling) expression, direct eye contact, clean studio background with soft directional light (typically 3:4 aspect ratio, waist-up crop). Demo 09's frame uses a burgundy inner border matching print letterhead conventions — this is the visual language partners recognise. Avoid overly friendly / casual portraits (they read as personal-injury advertising and hurt the firm's positioning in premium corporate / securities / M&A practice areas). 3. Reveal choice. The vertical top-to-bottom curtain in Demo 09 reads as photographic and formal — the same visual language as a print-run portrait developing on paper. Alternatives like the fintech horizontal-inset curtain (Demo 01) or the SaaS radial spotlight (Demo 03) read as too playful for the legal register; the counter-zoom + top-down clip-path is the tone-appropriate combination. Ship the compliant disclaimer + the register-appropriate portrait + the vertical curtain reveal, and the bio page performs both as a rankings target and as a business-development conversion surface.