bug(cdkTextareaAutosize): cdkTextareaAutosize does not resize when the placeholder or label is long

[jermowery]

Reproduction

https://stackblitz.com/edit/angular-2ebx1r?file=src/app/./text-field-autosize-textarea-example.html

Expected Behavior

What behavior were you expecting to see?

When a textarea has a long placeholder or label and the textarea using cdkTextareaAutosize, the text area should be auto-sized to support the length of the placeholder

Actual Behavior

What behavior did you actually see?

The text area does not auto-size to the placeholder or label used, and instead stays at the min number of rows and shows an internal (scrollbar?) the scroll through the placeholder

Environment

• Angular: latest
• CDK/Material: latest
• Browser(s): all
• Operating System (e.g. Windows, macOS, Ubuntu): all

[jelbourn]

@mmalerba @crisbeto we don't currently have the autosize directive respond to the placeholder text. Do you think this is something it should support?

[crisbeto]

It sounds reasonable to me, considering that the placeholder wraps on textarea, rather than truncating like on input.

My concern is how we would handle the case where the placeholder is longer than the value. Would the height collapse when the user focuses the input and the placeholder disappears? It might also be weird if there's a short value with a long placeholder where clearing the input would cause the textarea to become taller.

[jermowery]

I am thinking that whatever minimizes movement might make the most sense, so if the placeholder is long and the data is small we shouldn't necessarily snap back to a smaller size as soon as the user begins editing

[mmalerba]

Maybe we should just never let the textarea get smaller than the height with the placeholder. I'm not sure it really makes sense to let it go smaller

[jelbourn]

My inclination would also be to make this an option that's probably off by default in order to avoid breaking layouts in existing apps.

[mmalerba]

I would prefer not to have it be an option, just because it adds complexity. Depending on how its implemented, I'm fairly confident it won't break too many people. We could at least try a presubmit and see how it goes

[jelbourn]

That's reasonable, we can see what the presubmit shows and go from there

[jermowery]

Is this currently being worked on? It is important for a launch we have coming up so I am trying to evaluate if we need to implement our own hacky fix or if the official fix will land first

[jelbourn]

I don't think anyone has picked it up yet- if you wanted to take a pass at a PR I think the code would be pretty straightforward. Otherwise I can see if someone pon the team has time to take a look in the next week.