Skip to content
This repository has been archived by the owner on Sep 5, 2024. It is now read-only.

scroll/focus issue with texarea inside md-input-container #6800

Closed
GustavSt opened this issue Jan 21, 2016 · 9 comments
Closed

scroll/focus issue with texarea inside md-input-container #6800

GustavSt opened this issue Jan 21, 2016 · 9 comments
Labels
P4: minor Minor issues. May not be fixed without community contributions.
Milestone

Comments

@GustavSt
Copy link

When the input-container has a max-height but the content of the textarea exceeds that, and also has overflow:auto when navigating or entering new text it automatically scroll to the top.

codepen(based in master since the codepens for 1.0.2 was broken), you need to enter the text area for it to show.

There are some similar issues regarding textarea, but they seem subtly different: example #6296, #3070
nearest one i think is #2007

@devversion
Copy link
Member

Yes, that's weird, I think it's mostly related to the actual textarea grow fix, I would suggest you to take a look at #5757

@mckenzielong
Copy link
Contributor

@devversion @ThomasBurleson There have been a few other issues that were similar to this in the past. Some of those issues were related to height being changed to auto which was causing the textarea to jump.

Not sure if that is still the cause here, haven't had a chance to poke around. I don't seem to have these problems with polymer's iron autogrow textarea which uses a 'mirror' div to show the textarea onscreen.

There are probably good reasons for not mimicking that implementation (it would be a major change 👎 )... just a suggestion 👍

@devversion
Copy link
Member

@mckenzielong I think a more user-friendly solution would be adding an attribute called min-rows. More information can you find here. Maybe you will build the docs of the PR, and take a look at the <textarea> demo

@mckenzielong
Copy link
Contributor

@devversion The iron implantation in general just seems cleaner to me, again just an opinion. The api is simple and the implementation doesn't try to be too clever.

Honestly 1.0 textarea behaviour is backwards to me considering it defaults to auto-growing. We have md-no-autogrow, we have rows. Apart from avoiding breaking existing behaviour that should be all we need(maybe max-rows similar to iron's implementation?)

min-rows from your pr seems like a good (though to me, temporary) way of avoiding changing the default behaviour until a larger release / the change is well documented.

As mentioned these are just opinions, I wouldn't expect such a change really. I long dropped the current implementation for polymer's iron version for in an internal project (during the .1x releases? something like that) and since similar issues keep popping up, figured I would make that suggestion 👍

@devversion
Copy link
Member

@mckenzielong I think minRows won't shouldn't be a temporary fix, it should simplify the usability of the <textarea>. As the iron textarea is adding a maxRows, which is obviously the contrary of minRows, both implementations are clean for the final user. Adding minRows adds a simple usage for creating several combinations of <md-textarea>. Let us iterate through a few combinations.

Iron Textarea

  • Fixed 5-rows Textarea : <md-textarea rows="5" max-rows="5">
  • Initial 5-rows Textarea (growing): <md-textarea rows="5">

Suggested

  • Fixed 5-rows Textarea: <md-textarea rows="5">
  • Initial 5-rows Textarea (growing): <md-textarea min-rows="5">

I think in this case, the suggested attribute usage is more user-friendly than the iron implementation.

@mckenzielong
Copy link
Contributor

Eh, it is really just squabbling over semantics. I am thinking more in terms of what the attribute rows means to someone who hasn't used ngMaterial. This is where I think polymer got it right. Rows sets the default rows.

In "Suggested" min-rows would set the 'default rows', and I assume it grow until rows (haven't had time to pull that source to see how this use case would behave)

That would also open up the use of md-no-autogrow to set a true fixed size textarea.

@devversion
Copy link
Member

I don't know, who defined the rows attribute for growing? I think rows can also mean, that it is fixed to the specified amount of rows. I think it's the best, if we receive more information from a team member. I can see, we both have different opinions (but that's important) :)

@mckenzielong
Copy link
Contributor

I don't know, who defined the rows attribute for growing? I think rows can also mean, that it is fixed to the specified amount of rows. I think it's the best, if we receive more information from a team member. I can see, we both have different opinions (but that's important) :)

👍 @ThomasBurleson maybe we can clarification on md-no-autogrow too... - I have an inclining it isn't behaving properly (regardless of the discussion above)

@GustavSt
Copy link
Author

It does seem like the text-area needs some fine tuning. I did manage to get a workaround working by putting the md-input-container inside a wrapping div that had the max-height and overflow: auto

shown here if anyone else finds themselves in the need of a quickfix

@ThomasBurleson ThomasBurleson added this to the Backlog milestone Feb 4, 2016
@ThomasBurleson ThomasBurleson added the P4: minor Minor issues. May not be fixed without community contributions. label Feb 4, 2016
@ThomasBurleson ThomasBurleson modified the milestones: Backlog, Deprecated Apr 20, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P4: minor Minor issues. May not be fixed without community contributions.
Projects
None yet
Development

No branches or pull requests

4 participants