Fix issues 132 and 151

[share-with-me]

No description provided.

[sushain97]

Did you figure out why this was added using git blame? I'm concerned about removing it without knowing why in case we regress on another front.

[share-with-me]

Um, Nop! I tried to figure out the code that was causing this. I will use git blame now!

[share-with-me]

Using git blame, it shows that you have made the latest modification to that line with commit message as in this link. How do I infer from this?

[sushain97]

I think that commit just fixed a bunch of style issues. You'll have to look backwards in time a bit.

[share-with-me]

Sure on it.

[share-with-me]

Um, the commit message says - Improve textarea mechanics.
The link to the blame where this line of code was added it link

[sushain97]

Well, that's not a helpful commit message.

[share-with-me]

Hmm yeah. But I believe removing it should not cause an issue right? As in, it is just synchronizing heights! We could add it very easily in the event we need it. Inputs?

[sushain97]

I might also want the textarea to not decrease if I increase it manually then type something. Some max approach? I need to think about the ideal behavior of this more...

I remember when we added auto-adjusting text boxes, I was hesitant but didn't really have much time to go through it with a more critical eye... The behavior is hard to get right.

[share-with-me]

I remember when we added auto-adjusting text boxes, I was hesitant but didn't really have much time to go through it with a more critical eye... The behavior is hard to get right.

I would wait on this to get the behaviour right :D

[Androbin]

How about this:

The textarea has a text height (given) and a view height (controlled).
Let's call their difference space (could be positive/negative/zero).

Text deletion:

• space == 0: decrease view height to match text height
• space < 0: do nothing
• space > 0: do nothing OR preserve space

Text addition:

• space == 0: increase view height to match text height
• space < 0: do nothing OR preserve space
• space > 0: do nothing

[Androbin]

By the way, I de-conflicted the PR in https://github.com/Androbin/apertium-html-tools/commit/604892df5f311e285e03951f7b3f1cbe65c8940c

[sushain97]

Is the space text height - view height or vice-versa in your proposal, @Androbin ?

[Androbin]

I define space = view height - text height

[sushain97]

Hmmm, what happens if I paste a block of text then? space > 0 before and then space < 0 after. Won't nothing happen?

[Androbin]

I can think of three basic options:

• never preserve space
• always preserve space
• don't increase space when space > 0 AND don't decrease space when space < 0

[Androbin]

We could also ensure that space > 0 at any time.

[sushain97]

@sushain97 We could also ensure that space > 0 at any time.

This isn't great. It shouldn't keep growing without a max-width.

[Androbin]

It shouldn't keep growing without a max-width.

@sushain97 We are talking about height, aren't we?

[Androbin]

But yeah, we could just use these CSS properties:

• max-height: 123px
• overscroll-y: auto

[sushain97]

@sushain97 We are talking about height, aren't we?

Oops, yes. I meant width.

But yeah, we could just use these CSS properties:

Indeed. But this needs to be taken into account in the JS as well since max-height does not override a manual height setting, I think...