feat(textarea): textarea shrinking and resizing

[crisbeto]

• Changes the textarea behavior to consider the "rows" attribute as the minimum, instead of the maximum, when auto-expanding the element.
• Adds a handle for vertically resizing the textarea element.
• Simplifies the logic for determining the textarea height.
• Makes the textarea sizing more accurate by using scrollHeight directly, instead of depending on the line height and amount of rows.
• Avoids potential issues where the textarea wouldn't resize when adding a newline.
• Adds the option to specify a maximum number of rows for a textarea via the max-rows attribute.

Fixes #7649.
Fixes #5919.
Fixes #8135.

BREAKING CHANGE
This changes the behavior from considering the "rows" attribute as the maximum to considering it as the minimum.

@ThomasBurleson @EladBezalel @devversion These are the textarea changes that we talked about and specced in the Google Doc.

[EladBezalel]

@crisbeto is it auto growing/shrinkning according the content?

[crisbeto]

It is.

[EladBezalel]

@topherfangio please take a look as well

[topherfangio]

@crisbeto This should be noted as a breaking change in the commit message (and it should have a label).

Just to confirm, this means that there is no longer a maximum size for the text area? Will this break any apps that depend on it having a maximum size?

[topherfangio]

Haven't used it much; do we need to deregister the drag gesture above (i.e. undo the $mdGesture.register?

[crisbeto]

I'd say so. I remember trying to find if there was a deregister method, but I couldn't find one.

[devversion]

The deregister function will be returned from the register call.

• https:/angular/material/blob/master/src/core/services/gesture/gesture.js#L401-L414

[crisbeto]

Yes @topherfangio, this is a breaking change. Mainly because the old behavior was: start at 1 row or fit any of the text and go until the rows are reached. The new behaviour treats the rows as a minimum.

[topherfangio]

@crisbeto Okay, awesome. Can you make sure to do a git commit --amend to add the BREAKING CHANGE notice to the commit message? It's important because we automatically generate a list of breaking changes when we build a new release, and this is what that script looks for :-)

[crisbeto]

Done, hopefully it's not too picky with the placement.

[topherfangio]

I just tested this locally and it looks pretty good, but I think there might be a small issue with the height calculation.

Particularly, when you have 5 rows of text (some might be newlines), there is about 20px of extra whitespace at the bottom. As soon as you start typing the 6th row, it does indeed grow, but only by a tiny amount so that there's only 8px of whitespace at the bottom. This was on both Chrome and Firefox, so I don't think it's browser-specific.

5 Rows

6 Rows

Also, is it true that once a user resizes the textarea, it no longer does any automatic resizing? If so, I think that's fine, but we may want to mention this in the docs. In fact, we may want to just add a Textarea Usage section to the docs with some additional info about how users should expect it to work and what options are available.

[crisbeto]

Regarding the height, I believe it's because 5 rows in the textarea don't necessarily translate to 5 lines of text. We use offsetHeight to measure the height of 1 row of text, but that measurement includes padding, which means that the more padding we have, the more the measurement will be offset. E.g. here's an example of 5 rows, but with 20px of padding:

I wouldn't say it's too much of an issue in our case, because the design doesn't have a lot of padding by default. I've tried using getComputedStyle to remove the padding, but that was also problematic because:

1. It didn't behave consistently between IE and other browsers.
2. We'd have to either call it on each keypress or assume that it would't change.

Otherwise I've also tried resizing the textarea purely with the rows attribute, but it wasn't reliable on IE either. And the other alternative is having a whole separate DOM element that mirrors the text and is being used for measurements, but that can turn into a big mess.

---

As for the resizing, I'll add some info in the docs.
Docs have been added.

[crisbeto]

I managed to work around those height/padding issues. Also updated the PR to include a max-rows attribute.

[topherfangio]

LGTM 👍

[cmacdonnacha]

Just wondering if this will be merged for the next release?