feat(textarea): add autosize directive

[fxck]

Here's the separated PR for autosize, so you can think about the logic and what not.

@jelbourn

A row's height is calculated from line-height of the element, but unless the line-height is explicitly set, its initial value is normal, so to be able to dynamically set rows depending on the height of the textarea, I need to find the actual line-height.

So I'm creating a temp textarea element, reseting it's paddings and margins, visually hiding it, setting the rows attribute to 1(default is 2, but I'm not sure how consistent is it across browsers, so I'm setting it explicitly) and getting it's height, removing the element afterwards. When line-height is actually explicitly set(doesn't matter if it's by ems, pixels, percents, getComputedStyles always returns pixel values), I'm simply returning it as a number and doing none of above.

Now that I have actual line-height, I'm setting the min-height of the element to be

user provided rows value * line-height I found

The rest is similar to how it was before when input event happens, height is set to auto and rows to the initial value, which allows me to get the real scrollHeight even if user is removing instead of adding characters, afterwards new rows is calculated by diving the new scrollHeight by lineHeight.

[jelbourn]

So, I spent many hours today exploring the autosize thing. I looked at Polymer's approach, which uses a "mirror" element with the same content as the textarea. I tried playing with the idea a bit using a mirror element with white-space: pre-wrap and was happy with the results in Chrome, Safari, and Firefox. However, IE and Edge have a problem: it seems that the line wrapping behavior is different in a textarea vs. a normal element. This mainly manifests when you have a space right when the wrap would naturally occur. I spent way too long trying to get this to work. The Polymer implementation suffers from this problem, and I'd like to avoid it.

So, going back to the scrollHeight approach, I agree after messing with it that we should not work with both rows and autosize at the same time. However, we should probably support minRows and maxRows. I put together a prototype of how I think this should look. All of this can be done in a standalone md-autosize directive that is not coupled to MdInput.

[jelbourn]

@fxck let me know if you want to go ahead with the PR, otherwise I can send a PR based on my approach from above.

[fxck]

I'll be busy for a week or two now, so depends on how fast you want it in. As long as we can agree on this..

we should not work with both rows and autosize at the same time

..it should be easy though.

[jelbourn]

@fxck If you're busy I can try to tackle this in the next week or so.

[jelbourn]

Closed in favor of #1846

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}