Where the idea came from

A few weeks ago someone asked on a forum how to recreate the Mammut hero — the one where a full-screen image pins to the viewport while text scrolls up over it. They called it "a simple, I think, parallax question."

Kind of! The Mammut hero is the type of effect that looks like one thing and turns out to be three things stacked. GSAP or Locomotive Scroll handle it beautifully, but it's also doable with position: sticky and twenty lines of JavaScript — handy when you don't want to pull in a whole library for a single hero.

I haven't built this on a real client project yet — the thread just made me curious enough to break it down. What follows is the version I'd share if someone asked me how to do it: the same composition Mammut uses, simplified down to the load-bearing primitives, plus a few small bits of production polish to round it out. Plain HTML and CSS, no framework needed. Live demo lives in the lab.

Three layers, not one

The illusion you're seeing on mammut.com is built from:

1. A sticky-positioned container that pins to the viewport.
2. An image inside it that translates slightly while pinned — the parallax-within-pin.
3. A text block placed after the sticky container in the DOM, which scrolls up at normal speed and passes over the pinned image.

The whole thing is wrapped in an outer block whose height determines how long the hero stays pinned. When that outer block's bottom hits the viewport bottom, the sticky element releases and the page continues normally.

That structure is the whole trick. Everything else is decoration.

The markup

<section class="hero-block">
  <!-- 1. The pinned container -->
  <div class="hero-sticky">
    <div class="hero-image"><img src="..." alt="..."></div>
    <div class="hero-title">
      <h1>Senior dev in the room.</h1>
    </div>
  </div>

  <!-- 2. The text that scrolls over -->
  <div class="hero-text">
    <p>Ivo Jerković is a full-stack developer…</p>
  </div>
</section>

The .hero-image and .hero-title are inside the sticky container so they get pinned along with it. The .hero-text is a sibling of .hero-sticky, sitting after it in the DOM. That ordering is what makes the text appear to scroll up over the image: as the user scrolls, the sticky element holds its position, and the text below comes up into view.

The CSS that does the work

.hero-block {
  position: relative;
  background: #000;
}

.hero-sticky {
  position: sticky;
  top: 0;
  height: 100vh;
  overflow: hidden;
}

.hero-image {
  position: absolute;
  top: -50px;
  left: 0;
  width: 100%;
  height: calc(100% + 300px);  /* slack for the translation */
  will-change: transform;
}
.hero-image img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

.hero-text {
  position: relative;
  max-width: 600px;
  margin: 0 0 0 auto;
  padding: 80vh 48px 80vh;     /* this padding is the hero's "duration" */
  color: white;
}

Two non-obvious details:

The image needs vertical slack. It gets top: -50px and height: calc(100% + 300px) so that when JS translates it upward by ~20% of the viewport height, no background shows through at the bottom edge. The slack budget has to be greater than the maximum translation distance.

The text padding is the scroll duration. That padding: 80vh 48px 80vh on .hero-text is what gives the hero its length. Make the padding taller and the image stays pinned longer. Make it shorter and the hero releases faster. There's no "scroll length" property to set — the height of the text block (plus padding) determines everything.

The JS — twenty lines

const block = document.getElementById('hero-block');
const image = document.querySelector('.hero-image');
const title = document.querySelector('.hero-title');

function update() {
  const rect = block.getBoundingClientRect();
  const vh = window.innerHeight;

  // Progress 0..1 across the block.
  // 0 = block top just locked to viewport top.
  // 1 = block bottom reached viewport bottom (about to release).
  const total = block.offsetHeight - vh;
  const scrolled = -rect.top;
  const progress = Math.max(0, Math.min(1, scrolled / total));

  // Translate as a fraction of viewport height, not pixels —
  // so the effect scales with screen size.
  image.style.transform = `translate3d(0, ${progress * vh * -0.18}px, 0)`;
  title.style.transform = `translate3d(0, ${progress * vh * -0.10}px, 0)`;
}

update();
window.addEventListener('scroll', update, { passive: true });

The whole "parallax" effect is one number: progress, a value between 0 and 1 representing how far through the sticky block the user has scrolled. Image moves 18% of viewport height across the whole sticky lifetime; title moves 10% — slightly faster relative motion, giving the depth cue.

That's the basic demo. It works — and for plenty of use cases, that's all you need. Three small additions make it production-friendly.

Three things to add before shipping

1. The scroll listener fires too often

update() runs on every single scroll event. On a 120Hz display, that can be 120 calls per second. The math is cheap but the layout reads (getBoundingClientRect, offsetHeight) are not — each one can force a layout if a previous frame queued style changes.

Wrap it in requestAnimationFrame with a ticking flag:

let ticking = false;
function onScroll() {
  if (ticking) return;
  ticking = true;
  requestAnimationFrame(() => {
    update();
    ticking = false;
  });
}
window.addEventListener('scroll', onScroll, { passive: true });

Now update() runs at most once per animation frame. On a 120Hz display that's still 120fps of smooth animation but you've stopped re-doing work between paints.

2. No prefers-reduced-motion handling

Some visitors have their OS set to "reduce motion" — parallax effects can be physically nauseating for them. Honor the preference and skip the translations:

const reduce = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

function update() {
  // …progress math…
  const imageY = reduce ? 0 : progress * vh * -0.18;
  const titleY = reduce ? 0 : progress * vh * -0.10;
  // …
}

The image still pins (that's a layout thing, not a motion thing) — only the drift is suppressed. The pinned-and-static version still reads correctly as a hero.

3. The listener runs even when the hero is off-screen

Once the user has scrolled past the hero, the update() math keeps running on every scroll for the rest of the page. Wasted work. Gate the listener with an IntersectionObserver:

let inView = false;
const io = new IntersectionObserver(([entry]) => {
  inView = entry.isIntersecting;
}, { rootMargin: '50% 0px' });
io.observe(block);

function onScroll() {
  if (!inView || ticking) return;
  // …
}

The rootMargin: '50% 0px' keeps the observer "active" for half a viewport of slack above and below the hero, so the math fires just before and just after the hero is visible — no flicker.

A few gotchas worth knowing about

iOS Safari and sticky inside transformed parents. If any ancestor of .hero-sticky has a transform, filter, will-change, or perspective other than none, sticky positioning breaks — silently. The element stops pinning. If your hero "kind of works on desktop but does nothing on iPhone," this is almost always why. Audit the parent chain.

backdrop-filter does the same thing. Burned me on this exact site — the header had backdrop-filter: blur(8px) and a fixed-position drawer inside it was being clipped to the header's box instead of the viewport. Same root cause: backdrop-filter establishes a containing block for fixed and sticky descendants.

The image-slack math is brittle. If you ever change the max translation in JS (say from 18% to 30% of viewport height), the CSS height: calc(100% + 300px) may no longer be enough slack — 30% of a 1080px desktop viewport is already 324px, over budget. Safer to express the slack as a function of viewport in CSS too: height: calc(100% + 25vh) keeps the two in lockstep.

object-position: center is fine until you have a tall vertical image on a wide landscape viewport, or vice versa. Then your subject ends up cropped weirdly. For hero images that need a specific focal point, set object-position to a fraction (50% 30%) and pick it deliberately per image.

Why I went vanilla here

Most posts about parallax heroes start with an animation library, and that's a great call when you need timeline orchestration or scroll-driven sequences. GSAP especially is hard to beat once the choreography gets complex. For this specific effect — a hero that pins and drifts — position: sticky and transform are already doing most of the work, so a library would mostly be along for the ride.

Twenty lines of vanilla JS, four CSS rules, and a clear mental model of what each layer is doing. That's the whole thing. The forum poster who asked the question had it right when they called it "simple" — once the three primitives are named, it really is.

Originally posted at ivojerkovic.com.