Feature Requests

Visualize where users click/tap on a published site Show scroll depth across all breakpoints Display interaction hotspots

The Core Issue: When generating Responsive Text Styles via framer.createTextStyle, there is no way to explicitly label the L (Desktop/1200px) tab in the Editor UI without breaking the internal CSS cascade on the standard Canvas breakpoints. The Context (How Framer works under the hood): Framer’s text style engine operates strictly top-down (Desktop-First). The Top-Level properties applied to the createTextStyle object (the "Base" style) natively act as the Desktop breakpoint (e.g., > 1200px). The breakpoints array handles the downward overrides (e.g., Tablet < 1200, Mobile < 810). The Problem: Because the Top-Level Base style secretly handles the 1200+ Desktop sizing, the Text Style Editor UI hides the minWidth input for it. Framer then naively assigns the labels L, M, and S sequentially to the explicit breakpoints provided in the array. This creates an impossible situation for Plugin Developers who want perfectly labeled, correct Breakpoints: Scenario A: Providing correct CSS logic ([810, 390]) If a plugin developer relies on the Base style to serve Desktop, and only passes the smaller overrides to the array: javascript const textStyle = await framer.createTextStyle({ fontSize: 24, // Serves Desktop natively breakpoints: [ { minWidth: 810, fontSize: 18 }, // Serves Tablet natively { minWidth: 390, fontSize: 16 } // Serves Mobile natively ] }); Status: Canvas rendering works flawlessly. The UI Bug: The Framer Editor UI incorrectly labels the first override (810) as the L tab. Users report this as a bug, complaining that "My Desktop breakpoint starts at 810 instead of 1200!" Scenario B: Forcing correct UI Labels ([1200, 810, 390]) To fix the UI confusion, if a plugin developer explicitly feeds a 1200 breakpoint into the array so that the L tab reads 1200: javascript const textStyle = await framer.createTextStyle({ fontSize: 24, // Base breakpoints: [ { minWidth: 1200, fontSize: 24 }, // Injected to force "L" to = 1200 { minWidth: 810, fontSize: 18 }, { minWidth: 390, fontSize: 16 } ] }); Status: The UI tabs look perfect (L=1200, M=810, S=390). The CSS Cascade Bug: Because the Base already covers Desktop, injecting a 1200 override disrupts the downward cascade. Framer evaluates the 1200 override against the Tablet canvas (< 1200), causing Tablet to fetch Desktop font sizes! It pushes all font values down one slot entirely on the live canvas. Feature Request: The createTextStyle API needs a way to visually tether the Top-Level Base style to a labeled minWidth (like 1200) inside the Editor UI. Currently, developers must choose between giving users Broken Font Rendering (Scenario B) or confusing UI Labels (Scenario A).

Hi guys! I recently started selling some merch, and since I fell totally in love with Framer after building my portfolio ( www.jonasleupe.com ), I kinda-hacked myself a webshop inside Framer by using Stripe's payment links: www.hallogoeiendag.be . And that's actually the point of this post — I'd love some good old stripe integration where I could have a shopping cart e-commerce system running inside Framer. It would make life so much easier.

An article I read today reminded me about one thing I really miss in Framer — an RSS support. I think it'd help to win over many bloggers. Plus, it'd help preserve one of the many open web standards, which some no-code sceptics might fear will disappear.

I manage multiple Framer projects and landing pages, and I need a public API to programmatically read and modify project structure. Right now I can't build external tools to audit layer structure across breakpoints, fix layout properties in bulk, or integrate Framer into automated workflows. What I'm requesting: Read API — access the layer tree, component properties, and breakpoint configurations Write API — modify layout properties (position, size, gap, padding, distribute) programmatically Plugin API extension — expose editor capabilities to external scripts via OAuth This would be a similar ecosystem to what Figma achieved with its Plugin and REST API.

Populating Framer Analytics events from external API calls. Whether for an " app.domain.com " (externally hosted) to " domain.com " (Framer hosted) conversion step or for any other external setup.

I'd love to see built-in support for showing different content based on a visitor's location using IP detection. Use case: I want to display location-specific content on my pricing page like framer does on their pricing page — different prices, currencies, or offers depending on where the visitor is located (e.g., USD pricing for US visitors, EUR for Europe, etc.). Current limitations: Right now, achieving this requires custom code, third-party APIs, and a lot of workarounds. It's not straightforward and can be tricky to implement reliably within Framer. Proposed solution: Native geolocation condition that detects visitor location Ability to set visibility rules like "Show this section if visitor is in [Country/Region]" Built-in support for common use cases like currency/pricing localization Why this would help: Essential for sites with international audiences Enables personalized experiences without complex custom code Keeps everything manageable within Framer's no-code/low-code environment This would be a game-changer for anyone building sites that serve a global audience.

Currently it seems only certain fields are allowed within ControlType.Array, it would be great to allow all field types such as ComponentInstance

A hook or API that can be used to reference canvas text & color styles to be used in code files (overrides/components). This keeps the design system consistent and doesn't require additional work from developer to maintain as designers add more styles.