Framer currently has no native support for CSS scroll snapping, and its existing Scroll Section ID property is statefully isolated—it cannot drive global UI like nav bars or background transitions without brittle custom code. This request asks for two tightly related capabilities that together close a significant gap for high-end, enterprise-grade scroll interactivity. --- 1. Native CSS Scroll Snap JS-based scroll snapping (e.g., Lenis) cannot replicate browser-native momentum physics, accessibility behavior, or rendering stability. These workarounds also violate strict enterprise security policies that prohibit third-party libraries and external CDNs—a constraint that is increasingly common and non-negotiable for enterprise clients. Requested: A UI toggle in the Scroll settings panel that applies scroll-snap-type to the container and scroll-snap-align to child elements — zero dependencies, no custom code required. --- 2. The Critical Gap: Scroll Section ID Bubbling Framer already supports Scroll Section ID as a property, but that state cannot cross component boundaries—and component boundaries are exactly where it needs to cross. A concrete example of where this breaks down: On a recent enterprise SaaS project, the hero section used full-viewport scroll-snapping slides to deliver a cinematic narrative—each slide revealing a new dimension of the product story. This is precisely the kind of high-fidelity interaction where native scroll physics are not optional; the feel of the snap directly affects whether the storytelling lands. I built a custom code component to make this work: a scroll container with scroll-snap-type: y mandatory and an IntersectionObserver scoped to the overflow container ( root: container , threshold: 0.5 ), watching child elements tagged with data-section-index attributes. Each section's visibility fired a corresponding Framer EventHandler —up to 12, exposed as property controls—so individual slides could trigger variant changes on a linked component instance on the canvas. It worked, but the IntersectionObserver was watching intersection relative to the overflow container, not the true viewport—an architectural constraint baked in from the start. The system broke entirely the moment those slides needed to affect elements that must exist outside the component by semantic necessity: A header logo that changes state when the user scrolls past the fold—where "the fold" is the second snap section, not a pixel offset A floating nav with anchor-link smooth scroll that should only appear below the fold A <nav> and a <main> are siblings in the document. Collapsing them into a shared parent component just to share scroll state breaks semantic HTML, undermines accessibility, and creates an architecture that cannot be maintained or handed off. The only remaining options— window event dispatchers, IntersectionObserver hacks, custom React context providers—are all brittle, invisible to Framer's variant system, and flagged immediately by enterprise security reviews that prohibit runtime DOM manipulation patterns outside approved frameworks. The result: The cinematic transitions that were central to the original design vision simply aren't possible within Framer's current constraints, no matter how much custom engineering you bring to the problem. The core failure: scroll state that originates inside a well-structured component has no supported path to influence the canvas around it. Requested: A mechanism to bubble the active Scroll Section ID up to the top-level canvas, consistent with how Framer's existing Flow feature propagates interaction state from child to parent. When a snapped section becomes active, its assigned ID should be selectable in the Scroll Transform and Variant Effect panels by any global layer—enabling scroll-driven transitions without custom code or unsafe component nesting. --- 3. Why This Matters These two features are architectural, not cosmetic. Together they: Eliminate dependency on third-party scroll libraries for any project requiring snapping Enable Framer to be used end-to-end on enterprise projects with strict security and compliance requirements Unlock a class of scroll-driven UI—section-aware navs, ambient background shifts, scroll-synced animations—that currently requires leaving Framer's visual layer entirely Keep complex interactivity accessible and performant by default, not by workaround The combined ask moves scroll interactivity from a fragile, code-dependent edge case to a first-class, supported Framer capability.
