A no javaScript way to make a textarea the same height as input?

,
#1

So what I mean by the title is, I’ve been trying to make a textarea element that is identical to the input element when no text is in either of them, but when the textarea is filled with text and goes to the second line, will resize automatically.

Where I’m having an issue is the size of the textarea. I’ve been trying to make both of them have a height of 1.5rem but in attempting to do so, the text area won’t go any smaller than what looks like 2rem, leaving a fair bit of space beneath the text, like it was set to show two rows of text.

I experimented with the edit-text widget, and normal textarea elements, but I haven’t been able to figure it out unfortunately.

Is there a way to change this behavior, either with CSS, or with tiddlywiki functions? a while back I saw a tiddlywiki with a textarea like what I’m aiming for, but for the life of me, I have no idea where it was :sweat_smile:

So, I’ve run out of ideas, and would appreciate someone’s help if they know how to do this.

Using textareas instead of inputs for fields?
#2

Try this:

<style> .customTextArea { min-height:1.5rem; resize:vertical; } </style>
<$edit-text tag="textarea" class="customTextArea" field="test" rows=1 minHeight="1.5rem;"/>
#3

Thank you, this is exactly what I’ve been trying for!

I haven’t encountered resize vertical before, and when I tried rows I put it in double quotes.

Mind if I ask why you have to use min height for both the class and the widget? is it a redundancy or does it have a specific behavior?

Edit: a behavior I noticed is when adding width 100% to the class, it returns to that same behavior where it’s a bit too tall. Would you happen to know a work around for this?

Edit 2: Found a work around! using min-width 100% avoids the issue!

#4

The rows="1" minHeight="1.5rem" widget params override the widget’s built-in “autoHeight” calculations.

The min-height:1.5rem; CSS attribute prevents manually resizing from being less than 1.5rem.

Note that rows=1 (without the double quotes) is allowable because the parameter value is a simple literal value with no embedded punctuation. In fact, the quotes could also be omitted for other parameters (except for the minHeight because the value contains a “.”), like this:

<$edit-text tag=textarea class=customTextArea field=test rows=1 minHeight="1.5rem"/>

Even so, using quotes around each parameter is probably the more typical syntax.

Note also that the minHeight="1.5rem" should not have the semi-colon (that was a copy/paste error in my post).

2 Likes
#5

I must say that I’m a bit confused. I too was after the behaviour that @Justin_H was looking for, but I can’t seem to make @EricShulman’s solution work when I copy and paste it on https://tiddlywiki.com (although I did remove the spurious ; in minHeight="1.5rem;").

The min-height:1.5rem; CSS attribute does prevent manually resizing from being less than 1.5rem, but as soon as I try to input a character in the edit-text area, it grows to what seems to be a predetermined height, much taller that the expected 1.5rem.

Is there some obvious prerequisite that I’m missing?

#6

@xcazin mind if I ask what browser you’re on?

Maybe it has something to do with that, I dunno. I know I had to also add height: auto !important; in with the class ro prevent it being resized by parent elements, so you could give that a try as well.

#7

@Justin_H I was just about to post the message below! Unfortunately, height: auto !important; didn’t change the outcome:

I’m afraid I got what was missing: @EricShulman’s trick does work anywhere I tried, except with Firefox 113/114 (latest) on my Macbook. The most frustrating is that it works on another, probably more recent, Macbook, bearing the same macOS Monterey… Needless to say, I did the comparison on the same wiki: https://tiddlywiki.com:

Capture d’écran 2023-06-19 à 15.52.47
Capture d’écran 2023-06-19 à 15.52.471934×948 76.2 KB

I guess I’ll have to live with it, unless someone has a clue? :pray:

#8

@Justin_H First, apologies for not even have thanked you for your suggestion :pray:

I actually found on Stack Overflow a workaround to what looks like a long standing Firefox bug; adding overflow-x: hidden; to the class does the trick, as the textarea height seemed to account for an invisible scrollbar!

Capture d’écran 2023-06-21 à 09.21.29
Capture d’écran 2023-06-21 à 09.21.291990×956 79 KB

So thank you and thank you @EricShulman!

#9

Coming back to the discussion because I’ve run into an odd issue.

When setting the height of the text editor from auto to a specific px, it causes the textarea to return to a large size.

Is there any sort of work around for this?

#10

Hi @Justin_H, I cannot reproduce but maybe I don’t understand what you are trying to do. Could you give us an example that we can paste on tiddlywiki.com?

#11

sure thing!

Using TiddlyWiki — a non-linear personal web notebook, I created a new blank tiddler, and typed the below into the edit text area.

<style> .customTextArea { min-height:1.5rem; resize:vertical; } </style>
<$edit-text tag=textarea class=customTextArea field=test rows=1 minHeight="1.5rem"/>

Saved and reopened it, and clicked in the editor height option just before the more dropdown arrow in the editor toolbar, and clicked the radio button for the option to use 400px, rather than auto.

The result is the customTextArea also having a height of 400px. I tried to changed the styles to:

<style> .customTextArea { min-height:1.5rem; resize:vertical; height: auto !important; } </style>

But that prevented it from dynamically resizing.

#12

The $:/config/TextEditor/EditorHeight/Mode value ("auto" or “fixed”) is being applied to ALL textarea elements rather than just the textarea elements within tiddler editors. To prevent the fixed setting from being applied to your customTextArea, you can add an autoHeight=yes param to that $edit-text widget, like this:

<style> .customTextArea { min-height:1.5rem; resize:vertical; } </style>
<$edit-text tag=textarea class=customTextArea field=test rows=1 autoHeight=yes minHeight="1.5rem"/>

-e

3 Likes
#13

That works perfectly!

Thank you for the help with this, I was worried it was something I wouldn’t be able to fix :grin:

#14

Might it be that you saw the prerelease, which appears this way becase (I think) it has the Codemirror plugin installed?

#15

Afraid not, it was from a users tiddlywiki, I remember visiting it looking for something else they were demo’ing, but found it by chance.

I am a fan of the codemirror plugin though, it looks fantastic, I just don’t (yet) have a need for it :grinning_face_with_smiling_eyes:

#16

Good to know indeed!