fix(textarea): support floating labels with slotted content by brandyscarney · Pull Request #31321 · ionic-team/ionic-framework

brandyscarney · 2026-08-03T21:16:50Z

Issue number: N/A

What is the current behavior?

Textareas with a floating label and a start or end slot always display the label in the floated state, regardless of whether the textarea contains a value:

without value	with value

What is the new behavior?

The floating label now behaves consistently regardless of whether start or end slots are present:
- It overlays the textarea when the field is empty.
- It floats when the textarea is focused or contains a value.
The height of textareas has been increased to ensure consistent sizing among all textareas.
Start slot content is now always positioned to the left of both the label and the input.
Additional screenshot tests have been added to verify these behavior and layout changes.
A follow-up ticket has been created to address the remaining UI differences between our leading/trailing content implementation and the md specification.

Does this introduce a breaking change?

Yes
No

Internal DOM Structure Changes

The internal DOM structure has been modified to support floating labels with slotted start and end content. Additionally, the structure of the component has been reorganized, with some elements now grouped differently than before. This may introduce breaking changes for developers who rely on the component's internal DOM structure or apply custom styling to internal elements.

The following internal elements have been modified:

Removed: <div class="textarea-wrapper-inner">
Renamed: <div class="start-slot-wrapper"> is now <div class="textarea-start">
Added: <div class="textarea-control"> wrapper for the label and native control
Renamed: <div class="end-slot-wrapper"> is now <div class="textarea-end">

While the public API has not changed, selectors or style overrides targeting the previous markup will need to be updated to reference the new element names and their organization. If you have custom CSS targeting the internal structure of textarea, update your selectors to account for these structural changes.

Minimum Height Change

The minimum height of textarea in Material Design (md mode) has been increased from 56px to 72px. This change ensures consistent heights across textareas regardless of the fill property or labelPlacement, providing a more uniform and predictable user experience. If you were relying on textareas being 56px tall or had custom CSS based on that value, you will need to either update your styles to accommodate the new 72px height or override it back to 56px if needed.

Other information

Preview

vercel · 2026-08-03T21:16:56Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
ionic-framework	Ready	Preview	Aug 7, 2026 9:18pm

brandyscarney · 2026-08-03T21:23:46Z

-              <slot name="start"></slot>
-            </div>
+          {hasOutlineFill && <div class="textarea-outline-container">{this.renderOutlineDecorations()}</div>}
+          <div class="textarea-start">


I renamed the slot wrapper divs from the following:

start-slot-wrapper → textarea-start

end-slot-wrapper → textarea-end

The goal was to align the naming with the wrapper elements added to Input.

This also matches our existing naming pattern with elements like input-bottom and textarea-bottom.

brandyscarney · 2026-08-03T21:52:45Z

I renamed these screenshots from textarea-slots to textarea-slot to match the folder name.

brandyscarney · 2026-08-03T21:53:09Z


 configs().forEach(({ title, screenshot, config }) => {
-  test.describe(title('textarea: start and end slots (visual checks)'), () => {
+  test.describe(title('textarea: slot'), () => {


This was updated to match the folder name, following how we title other tests.

…re changed

ShaneK

Looking really good! I found a few things that I believe are problems, please let me know if I'm off base here!

ShaneK · 2026-08-07T17:42:11Z

+// ----------------------------------------------------------------
+
+.textarea-control {
+  @include padding(var(--padding-top), 0px, var(--padding-bottom), 0px);


The padding moved here but .native-wrapper::after still has its own copy, so auto-grow counts it twice. An auto-grow textarea with 3 lines comes out 26px taller than the same content with rows="3" on md, and 18px on ios, which matches --padding-top + --padding-bottom exactly.

The ::after is the sizing replica so it has to mirror the real textarea's box, and the textarea has no padding now. Dropping the padding include from ::after and re-recording the auto-grow snapshots should do it.

I'd want to see this one fixed before approving since it hits every auto-grow textarea.

ShaneK · 2026-08-07T17:44:46Z

+
+  align-items: start;
+
+  width: 100%;


Missing min-height: inherit here. The old .textarea-wrapper-inner had it, and that's what passed the host's min-height down to .native-wrapper. Without it .native-wrapper inherits auto, so min-height: 200px on the textarea gives you a 200px box with a 45px editable area and 155px you can't type in. Works fine on major-9.0.

The obvious fix overshoots a little though, since .native-wrapper re-inherits the same value and pushes the control out by its own padding, so it may want align-self: stretch instead.

Expected:

But when it's not filled it's more like:

ShaneK · 2026-08-07T17:47:10Z

+
+:host(.textarea-label-placement-floating) .textarea-control,
+:host(.textarea-label-placement-stacked) .textarea-control {
+  --padding-top: 0px;


This kills --padding-top as a public property for floating and stacked. Before, the zeroing was on :host() so an outer-tree declaration still won. Now it's on an internal element nobody can outrank, so --padding-top: 40px on a floating textarea does nothing, while it still applies on start.

The host sets it to 20px a few lines up only so the ::slotted rule can read it for the slot offset, so I think a separate internal property for that would let --padding-top: 0px go back on :host(). If losing the override is intentional it should be in BREAKING.md.

ShaneK · 2026-08-07T17:51:03Z

-    if (ev.target === ev.currentTarget) {
-      ev.stopPropagation();
-    }
+    ev.stopPropagation();


Was there a reason for dropping the target check? It came in with #30384 for #30165.

Since the label now wraps .textarea-start and .textarea-end, clicking slotted content doesn't propagate past ion-textarea any more. Clicking a slotted ion-button still fires its own handler, but a listener on a wrapping ion-item or on document gets nothing, where on major-9.0 both fire once. That takes out click tracking and click-outside handlers over that part of the field.

The item tests don't catch it because onClickCapture intercepts the native textarea path before the label handler runs. Same change is in the input PR.

This also happens if you use something like a dynamic font and it lazy loads in after the input renders and the size is different, but in that case it doesn't fix itself ever.

Input fix: 9b59417

Textarea fix: 58708ca

Select fix: b5a1d65

ShaneK · 2026-08-07T17:52:48Z

-     */
-    return this.renderLabel();
+
+    const startSlotWidth = startSlot.getBoundingClientRect().width;


Reading layout during render() is a bit shaky here. There's no re-measure once the element becomes visible, so a textarea that first renders in a hidden container (inline modal, inactive tab, collapsed accordion) gets 0px and keeps it, and the floating label ends up sitting over the start icon. It fixes itself on first focus, which makes it easy to miss in manual testing.

A ResizeObserver on .textarea-start set up in componentDidLoad would cover this and the stale-measurement case together, and notch-controller.ts already solves the same hidden-element problem for the notch.

Since this method is identical in the input PR, might be worth pulling into utils/forms/ next to createNotchController.

ShaneK · 2026-08-07T17:54:40Z

+
+    const startSlotWidth = startSlot.getBoundingClientRect().width;
+    const roundedWidth = Math.round(startSlotWidth * 10) / 10;
+    const isRTL = document.dir === 'rtl';


Using document.dir here misses element-level direction, so a textarea inside a dir="rtl" container on an LTR page gets the sign flipped the wrong way. The RTL screenshots won't catch it since the test harness sets dir on <html>.

The transform mixin auto-flips translate3d but not translate, so switching the outline rule to translate3d(var(--start-slot-adjustment), -32%, 0) would let the mixin handle direction and this sign logic could go away.

ShaneK · 2026-08-07T17:58:26Z

+
+:host(.textarea-label-placement-floating),
+:host(.textarea-label-placement-stacked) {
+  --padding-top: 20px;


This block is identical in textarea.ios.scss, and it replaced a rule that used to live in the shared textarea.scss. Could it go back there? Same values in both mode files means they can drift.

…Callback

feat(textarea): support floating labels with slotted content

4b6186b

brandyscarney changed the base branch from main to major-9.0 August 3, 2026 21:17

github-actions Bot added package: core @ionic/core package package: angular @ionic/angular package package: vue @ionic/vue package package: react @ionic/react package labels Aug 3, 2026

brandyscarney commented Aug 3, 2026

View reviewed changes

brandyscarney added 2 commits August 3, 2026 17:51

test(textarea): rename tests and add fill and rtl coverage

bbcc734

chore(): remove old snapshots

2662a5c

github-actions Bot removed package: angular @ionic/angular package package: vue @ionic/vue package package: react @ionic/react package labels Aug 3, 2026

brandyscarney commented Aug 3, 2026

View reviewed changes

chore(): add updated snapshots

5efd430

vercel Bot deployed to Preview August 3, 2026 22:00 View deployment

fix(textarea): target buttons specifically for smaller margin top

667da5c

vercel Bot deployed to Preview August 3, 2026 22:24 View deployment

Ionitron and others added 2 commits August 4, 2026 14:19

chore(): add updated snapshots

450d154

docs(breaking): add a section for textarea structural changes

86bdbf7

vercel Bot deployed to Preview August 5, 2026 16:11 View deployment

copy editing

4f02aa9

vercel Bot deployed to Preview August 5, 2026 16:24 View deployment

brandyscarney added 2 commits August 5, 2026 15:19

docs(breaking): add a note about the min height change

bf98a5d

Merge branch 'major-9.0' into FW-6471-textarea

c25a43b

vercel Bot deployed to Preview August 5, 2026 19:26 View deployment

fix(textarea): disable the label transition when start or end slots a…

3c75c3f

…re changed

vercel Bot deployed to Preview August 6, 2026 19:43 View deployment

brandyscarney mentioned this pull request Aug 6, 2026

docs(updating): update v9 migration guide to add missing breaking changes ionic-team/ionic-docs#4620

Open

trigger actions after outage

c5c726f

vercel Bot deployed to Preview August 7, 2026 13:51 View deployment

brandyscarney marked this pull request as ready for review August 7, 2026 14:35

brandyscarney requested a review from a team as a code owner August 7, 2026 14:35

brandyscarney requested a review from gnbm August 7, 2026 14:35

ShaneK requested changes Aug 7, 2026

View reviewed changes

fix(textarea): allow click propagation for slotted content

58708ca

vercel Bot deployed to Preview August 7, 2026 19:39 View deployment

brandyscarney added 2 commits August 7, 2026 17:04

refactor(textarea): mark slot var as internal and add fallback

a595a64

refactor(textarea): call raf from utils and cancel it in disconnected…

6278723

…Callback

vercel Bot deployed to Preview August 7, 2026 21:18 View deployment

Navigation Menu

Uh oh!

fix(textarea): support floating labels with slotted content - #31321

fix(textarea): support floating labels with slotted content#31321
brandyscarney wants to merge 15 commits into
major-9.0from
FW-6471-textarea

brandyscarney commented Aug 3, 2026 •

edited

Loading

Uh oh!

vercel Bot commented Aug 3, 2026 •

edited

Loading

Uh oh!

brandyscarney Aug 3, 2026 •

edited

Loading

Uh oh!

brandyscarney Aug 3, 2026

Uh oh!

brandyscarney Aug 3, 2026

Uh oh!

ShaneK left a comment

Uh oh!

ShaneK Aug 7, 2026

Uh oh!

ShaneK Aug 7, 2026

Uh oh!

ShaneK Aug 7, 2026

Uh oh!

ShaneK Aug 7, 2026

Uh oh!

brandyscarney Aug 7, 2026 •

edited

Loading

Uh oh!

ShaneK Aug 7, 2026

Uh oh!

ShaneK Aug 7, 2026

Uh oh!

ShaneK Aug 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

brandyscarney commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is the current behavior?

What is the new behavior?

Does this introduce a breaking change?

Other information

Uh oh!

vercel Bot commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brandyscarney Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShaneK left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brandyscarney Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

brandyscarney commented Aug 3, 2026 •

edited

Loading

vercel Bot commented Aug 3, 2026 •

edited

Loading

brandyscarney Aug 3, 2026 •

edited

Loading

brandyscarney Aug 7, 2026 •

edited

Loading