# Could long footnotes be scrollable?
**URL:** https://meta.discourse.org/t/could-long-footnotes-be-scrollable/409613
**Category:** Feature
**Tags:** footnote, fixed
**Created:** [August 9, 2026, 3:16am UTC](https://meta.discourse.org/t/could-long-footnotes-be-scrollable/409613 "2026-08-09T03:16:11Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@one1](https://meta.discourse.org/u/one1)
#### Post date: [August 9, 2026, 3:16am UTC](https://meta.discourse.org/t/could-long-footnotes-be-scrollable/409613/1 "2026-08-09T03:16:11Z")
Has their been any thought about making footnote popups scrollable? See π\[1\] There are four paragraphs.
Of course long footnotes are probably not a good idea just because. And one solution would be to have end notes instead of the popups. But since itβs a site wide setting, this isnβt an option on individual posts.
Also there is a bug with quoted paragraphs. Usually you can put a blank line with just a `>` to get a quoted blank line. I can make a new issue for that if need be.
Possibly related (but unresolved?): [Problems with scrolling on mobile footnote](https://meta.discourse.org/t/problems-with-scolling-on-mobile-footnote/219714)
* * *
1. PARAGRAPH 1 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin ultricies porta tincidunt. Phasellus vitae luctus nulla. Proin condimentum urna at leo consectetur, sit amet finibus eros rhoncus. Vestibulum sed congue nisi. Nam molestie tortor vitae risus finibus hendrerit. Nunc nec varius nibh. Maecenas vel neque dui. Praesent vel maximus justo, et rutrum eros. Aliquam ultricies lorem lorem, vitae commodo diam mollis quis. Nunc vitae tortor convallis, rutrum augue id, vestibulum tellus. Pellentesque accumsan nec eros quis dapibus.
---
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [August 9, 2026, 3:17am UTC](https://meta.discourse.org/t/could-long-footnotes-be-scrollable/409613/2 "2026-08-09T03:17:18Z")
> [@one1](#):
>
> Also there is a bug with quoted paragraphs. Usually you can put a blank line with just a `>` to get a quoted blank line. I can make a new issue for that if need be.
please post a separate #Contribute > Bug topic for this
---
### Author:  [@Canapin](https://meta.discourse.org/u/Canapin)
#### Post date: [August 10, 2026, 4:56pm UTC](https://meta.discourse.org/t/could-long-footnotes-be-scrollable/409613/3 "2026-08-10T16:56:43Z")
> [@one1](#):
>
> See π There are four paragraphs.
Yeah, very glitchy on mobile.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [August 10, 2026, 5:17pm UTC](https://meta.discourse.org/t/could-long-footnotes-be-scrollable/409613/4 "2026-08-10T17:17:35Z")
Iβm using footnotes, a lot, to show i.e. AI-explanations and similar. And those are quite often longer texts. So, to get such text masses scrollable is quite cruicial for me π€·ββοΈ
---
### Author:  [@one1](https://meta.discourse.org/u/one1)
#### Post date: [August 11, 2026, 2:51am UTC](https://meta.discourse.org/t/could-long-footnotes-be-scrollable/409613/5 "2026-08-11T02:51:43Z")
I donβt know if it matters, but @Jagster ans @Canapin you could give the topic an upvote.
(Devs: do these up votes even matter?)
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [August 11, 2026, 1:45pm UTC](https://meta.discourse.org/t/could-long-footnotes-be-scrollable/409613/7 "2026-08-11T13:45:59Z")
This should hopefully make long footnotes better π
>
>
> FloatKit gives a tooltip a fixed \`maxWidth\` and no height limit at all. That is β¦fine for the short labels most tooltips carry, but it breaks down as soon as one holds user content β footnotes, chat reaction lists and event descriptions all render arbitrary-length HTML into a tooltip, and the result is a popup bigger than the screen it has to fit on.
>
> Neither axis recovers on its own, because floating-ui's \`shift\` can only \*move\* a float, never shrink it.
>
> \*\*Vertically\*\* it clamps the popup flush under the header and leaves the rest below the fold. Because the float is re-anchored to its trigger on every scroll, its viewport rectangle never changes, so the hidden part cannot be reached by scrolling β the page just slides underneath it. Measured on a 390Γ664 phone with a long footnote: a 1557px popup with 945px permanently unreachable, and swiping inside it scrolled the page from 871 to 1381 while revealing nothing.
>
> \*\*Horizontally\*\* the same clamp pins a 350px popup 10px from the left edge of a 320px screen, so the overflow joins the document's scrollable area and the whole page β header included β can be panned sideways (42px, growing with each pan).
>
> \## What changed
>
> \- \`.fk-d-tooltip\_\_inner-content\` is bounded to \`60dvh\` and scrolls, which is what menus have done since they gained \`overflow: auto\`. Tooltips kept the \`overflow: hidden\` they were born with and were simply never revisited, so the asymmetry was drift rather than a decision.
> \- Alignment becomes \`align-items: safe center\` at the same time. The cross axis is the one being capped, so plain \`center\` would centre content that is too tall and push its first lines above the scrollport, where scrolling cannot follow β measured at 830px out of reach.
> \- \`maxWidth\` is clamped against the space the viewport actually leaves, derived from the same padding \`shift\` keeps clear so the two cannot disagree.
> \- Only \*numeric\* \`maxWidth\` values are clamped. The option also accepts CSS keywords (the user card passes \`unset\`), and wrapping a keyword in \`min()\` is invalid CSS β the browser would drop the declaration and hand the float to whatever stylesheet rule was previously being overridden.
>
> \`overflow-x\` stays \`hidden\` rather than becoming \`auto\`: the same rule carries \`overflow-wrap: break-word\`, so \`auto\` on both axes would give tooltips a horizontal scrollbar for unbreakable content.
>
> \## Before / after
>
> A long footnote on a 390px-wide phone, and the same popup after swiping inside it:
>
> | | Before | After |
> |---|---|---|
> | popup height | 1557px | 400px |
> | clipped below the fold | 945px | 0 |
> | scrollable | no | yes (1157px of scroll) |
> | swiping inside it | scrolls the page, popup unchanged | scrolls the footnote, page stays put |
> | 320px screen | 352px wide, page pans 42px | 302px wide, no pan |
>
> \
> \
> \
>
>
> \## Testing
>
> \- \`d-tooltip-test.gjs\` gains a height/scroll test and a keyword-\`maxWidth\` test, and the two numeric \`maxWidth\` cases are folded into one. Each new assertion was checked to fail against the specific declaration it guards: dropping \`safe\`, \`box-sizing\`, or \`max-height\` each turn the scroll test red, and wrapping keywords in \`min()\` turns the keyword test red.
> \- A footnote system spec covers the end-to-end mobile case at 320px β real cooked content, real touch scroll, and the document-level horizontal overflow that a rendering test cannot observe.
> \- Ran the tooltip- and menu-heavy core system specs (cards, user tips, filter navigation, styleguide, localization menus, composer, bookmarks, chat reactions, calendar) β ~200 examples, no new failures.
---
### Author:  [@one1](https://meta.discourse.org/u/one1)
#### Post date: [August 11, 2026, 2:53pm UTC](https://meta.discourse.org/t/could-long-footnotes-be-scrollable/409613/8 "2026-08-11T14:53:12Z")
Thanks so much. This is such an amazing community.
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [August 14, 2026, 3:58pm UTC](https://meta.discourse.org/t/could-long-footnotes-be-scrollable/409613/10 "2026-08-14T15:58:04Z")