Your (Flux UI) Rich Text Editor (Probably) Shouldn't Have a Scrollbar

I was editing a campaign page in Growth Method and noticed the rich text editor had a scrollbar. The hypothesis text was longer than the editor’s visible area, so part of it was hidden — scrollable, but not visible. It felt wrong, but I wasn’t sure if it was a bug or the standard behaviour.

I asked:

Is there a way to ensure there is never a scrollbar on the Flux UI editor component? The editor should expand to fit the text. Or is this a UI/UX anti-pattern? Do most tools/UIs like this include a scrollbar? What’s the norm?

Table of contents

The default behaviour

Flux UI’s <flux:editor> component ships with a minimum height of 200px and a maximum height of 500px. As you type, the editor grows from 200px up to 500px. Once your content exceeds 500px tall, a scrollbar appears inside the editor.

This means on a full-page form — like a campaign edit page — you end up with two scrollbars: one for the page and one inside the editor. The page scrolls, and the editor scrolls independently within it.

Designers call this “nested scrolling” — two independent scroll areas fighting for attention. Users lose track of where they are, and the editing experience feels cramped.

UX research backs this up. Baymard Institute found that 26% of sites get inline scroll areas wrong, identifying five core problems: lack of overview, scroll hijacking, invisible content, overly sensitive scrollbars, and accidental “activation” of nested scroll areas. Accessibility expert Sheri Byrne-Haber calls nested scrollbars “one of the biggest accessibility evils, ever”, noting they harm keyboard users, switch users, screen reader users, people with tremors, and mobile users.

There’s also what Nielsen Norman Group calls the “illusion of completeness” — when visible content appears complete, but more exists outside the viewable area. As they put it: “Thinking a page is complete — when it isn’t — is a serious usability failure.” A scrollbar inside an editor creates exactly this problem: users can’t see everything they’ve written.

Context is everything

The 500px default isn’t wrong — it’s designed for one context and applied to another.

Embedded editors (chat inputs, comment boxes, modals) should be bounded. Slack’s message input grows to a point, then scrolls. GitHub’s comment box has a fixed height. That makes sense — the editor is a small part of a larger layout, and you don’t want it pushing everything else off-screen.

Full-page editors (document editors, CMS forms, edit pages) should auto-expand. Notion, Linear, and Google Docs all let the editor grow as tall as the content needs. The page itself is the scroll container — the editor just flows within it. Google’s Material Design spec makes this explicit: multi-line text fields should “wrap text onto a new line by expanding the bottom of the field, shifting screen elements downward.” Zendesk Garden and Atlassian’s design system both offer auto-expand modes for the same reason.

Nielsen Norman Group’s form usability guidelines reinforce this: “Text fields should be about the same size as the expected input since it’s extremely error prone when users can’t see their full entry.”

The rule of thumb: if the editor is the page content, let it grow. If the editor is embedded in a larger layout, bound it.

Three options

Option A: Fully auto-expand (remove the cap)

Remove the max height entirely. The editor grows with content, no scrollbar ever.

<flux:editor
    wire:model="description"
    class="**:data-[slot=content]:max-h-none! **:data-[slot=content]:min-h-[100px]!"
/>

Option B: Keep the 500px default

Leave Flux’s default behaviour. The editor caps at 500px and scrolls beyond that.

<flux:editor wire:model="description" />

Option C: Raise the cap

Set a higher max height (like 800px) as a compromise.

<flux:editor
    wire:model="description"
    class="**:data-[slot=content]:max-h-[800px]! **:data-[slot=content]:min-h-[100px]!"
/>

For Growth Method’s campaign edit pages — full-page forms where the hypothesis, design, and results are the primary content — Option A is the right choice. The page already scrolls — let the editor grow with it.

The ! modifier gotcha

If you try this without the ! (Tailwind’s important modifier), it won’t work. The Flux editor’s internal styles have enough specificity to override your custom classes.

This tripped up other developers too. In GitHub issue #1506, a user reported that the height customisation documented on the Flux editor page didn’t work. Josh Hanley from the Flux core team confirmed:

I think since Flux v2 released, the documented example doesn’t work any more. I’ve updated the documentation examples to include the !.

So always include the ! on both min-h and max-h overrides.

How the CSS targeting works

The class **:data-[slot=content]:max-h-none! looks intimidating, but it breaks down simply:

• **: — target any descendant element
• data-[slot=content]: — that has the attribute data-slot="content" (this is the editor’s content area)
• max-h-none! — remove the max height, with ! for important

This is the same pattern the Flux docs recommend. It’s a Tailwind technique for styling a nested element inline, without needing direct access to the component’s internal markup.

Flux already supports this pattern

Flux’s <flux:textarea> component already has a built-in rows="auto" prop that auto-expands to fit content — no max height, no scrollbar. Caleb Porzio (the creator of Livewire and Flux) considers auto-expansion a first-class pattern.

The <flux:editor> component doesn’t have an equivalent prop (yet), but the CSS override achieves the same result.

The fix in practice

Here’s the change applied to Growth Method’s campaign edit page:

<flux:editor
    wire:model="description"
    class="**:data-[slot=content]:max-h-none! **:data-[slot=content]:min-h-[100px]!"
/>

The same class applies to all three editors on the page — hypothesis, design, and results. Each starts at 100px tall when empty and grows with content. No scrollbar, no hidden content.

What would Taylor Otwell do?

Taylor favours simplicity — the right tool for the context, not the most configurable one. He wouldn’t leave a 500px cap on a full-page document editor. That’s a constraint designed for a different layout. He’d remove it, use the framework’s built-in CSS override, and move on.

His own products (Laravel Nova, Laravel Cloud) use auto-expanding text areas in form contexts. Option A — the simplest option with the fewest arbitrary decisions — is the Taylor Otwell choice.