S
Simon Hagleitner
I've spent way too many hours chatting with Claude to make this feature happen for my client, and since you guys are all into AI right now anyway, I asked Claude to summarize the struggle, the journey and what needs to be done:
Summary
There is no native way in Framer to place an inline tooltip trigger inside flowing Rich Text — e.g. a dotted-underlined term or an (i) icon next to a word that reveals a short explanation on hover/tap. This is a basic, expected UX pattern, and its absence forces elaborate DOM workarounds that are fragile and hard to maintain. For content-heavy client work this has become a real blocker.
Why this matters (UX context)
Inline tooltips and glossary terms are a long-established convention, especially in finance, legal, medical, and technical content — any domain where a single term needs a one-line explanation without breaking the reading flow. A dotted underline signalling "this term has a definition", or a small (i) after a sentence for extra context, is something users understand instinctively. It is not a nice-to-have; for regulated content like investment disclaimers or cost ratios, it is often how required explanations get surfaced without cluttering the page.
The core gap
The problem is structural, not cosmetic. Two things are missing:
  • No way to embed an interactive element inline within a Rich Text flow. Components can only be added as blocks between paragraphs, not mid-sentence next to a specific word. Rich Text is effectively a black box you cannot reach into from the layout.
  • No CMS access from code. Since the code API to collections was removed, there is no supported way for a code component to read collection data at runtime. Any data-driven tooltip logic therefore cannot pull its content from the CMS directly.
Together these mean: the trigger can't live inline, and the content can't come from the CMS through any clean path.
How we had to hack around it
To ship this on a paid client project (a Swiss fintech), we built a code component that:
  • Scans the rendered DOM for Rich Text links using a marker convention (#tip=slug / #info=slug), since a Rich Text link is the only thing that can be placed truly inline on a specific word.
  • Intercepts clicks before Framer's router handles them, because otherwise the hash link triggers navigation.
  • Injects the (i) icon and a positioned tooltip bubble into the DOM manually.
  • For CMS-sourced content, renders the entire glossary as a hidden, opacity-0 Collection List on every page, then reads the text back out of the DOM via data-framer-name layer-name conventions — because that is the only way to get CMS data to the client without a code API.
Every layer of this is a workaround for a missing primitive. Along the way we hit and had to defend against:
  • Framer's router redirecting hash links to /home on iOS.
  • Hydration timing, where the first tap navigates before the script is active.
  • Long link values being silently rewritten to href="./" — breaking any tooltip whose text exceeds an undocumented length, a hard wall for exactly the long legal disclaimers that most need a tooltip.
  • Baseline alignment, spacing, and mobile tap handling of the injected icon.
  • The SEO/GEO cost of duplicating hidden glossary text into the DOM of every page.
Why this is a problem worth fixing
Bluntly: this is a standard feature, and it took days of engineering plus several fragile hacks to approximate it. On well-paid client projects, "we can't do inline tooltips cleanly" is the kind of gap that makes clients question the platform choice — and it's a genuine differentiator for Webflow and especially WordPress, where inline glossary terms sourced from a CMS are a solved, native problem via shortcodes and CMS-bound embeds. It's a little embarrassing to tell a client that a pattern they've seen on countless sites requires a custom DOM-scanning script that reads content out of hidden elements.
What would actually solve it (in rough order of impact)
  • A native inline tooltip / annotation in Rich Text — select a word, attach a short text (static or CMS-bound), choose trigger style (underline / icon) and hover-or-tap behaviour. This alone solves 90% of the need.
  • The ability to place a component inline within a Rich Text run, not only as a block — which would let the community build tooltip components properly.
  • A supported way to read CMS collection data from code (even read-only), removing the need to render hidden content into the DOM just to access it.
Any one of these would remove most of the hacking. The first would make Framer's Rich Text competitive with the tools clients compare it to for content-heavy work.
Happy to share the live site and walk you through the implementation if that's useful.