iron-autogrow-textarea
iron-autogrow-textarea copied to clipboard
PolymerElements
Wrapped lines expand textarea with available space
On an iron-autogrow-textarea with empty lines, a single long line will not take up one of these, and will instead expand the text area.
Steps to reproduce:
- Create an iron-autogrow-textarea element with an initial number of rows.
<iron-autogrow-textarea rows="4></iron-autogrow-textarea> - Type a single long line into the text area so that the line wraps.
- The text area expands instead of using available space.
@nloewen I think this is related to https://github.com/PolymerElements/paper-input/issues/125, and it's happening because the textarea's nor its parent have a fixed/max size. Does that explanation make sense?
Fixing the text area's height takes the autogrow out of iron-autogrow-textarea and overrides the rows property. Setting a maximum height means that the text area displays this bug until it reaches said maximum height. Fixing the parents height just means that the text area overflows it's parent when it reaches that size.
The issue seems to be that _constrain() doesn't consider a line wrap as a new line. If a line wraps onto a second, it should count towards the total line count for the purposes of sizing the text area
I agree line wraps should count when limiting text area's size; does anyone have an idea of how to fix that? Or will it be fixed on next versions?
A way to fix it is to use a canvas measure or a aria pixel plot measure which calculates pixel distance to line end and then clicks the row max counter at that distance.
We implemented the same for a line numbering, paragraph reading, and syllabic word breaker, which calculated word length and distance to end line to determine both when a word should wrap abs when wrap was insufficient and a word break was needed. Here, zero is zero so less than one pixel would do the trick.
A way to fix it is to use a canvas measure or a aria pixel plot measure which calculates pixel distance to line end and then clicks the row max counter at that distance.
We implemented the same for a line numbering, paragraph reading, and syllabic word breaker, which calculated word length and distance to end line to determine both when a word should wrap abs when wrap was insufficient and a word break was needed. Here, zero is zero so less than one pixel would do the trick.
Is this an issue related to a swap in policies regarding white space clipping in browsers to facilitate both template strings and Dom parsing
My understanding is that the newer, followed spec will leave the space, and then a CSS approach or a /^\s*(?!:\b) /g should do all save a space in all new lines
There are other reg ex approaches
I know there is something in CSS and that polymer specifically has a strip white space "call" that is simple to use. If it wasn't removed.
It's I the docs.
Will look for you when I get home off you need it
Sent from my iPhone
On Oct 3, 2016, at 7:59 AM, Jimmy Vithalani [email protected] wrote:
Which version is it slotted in?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.