HTML Forms - Textareas

Chapter 37 16 mins

Learning outcomes:

  1. The <textarea> element
  2. A simple example of a <textarea>
  3. The initial value of a <textarea>
  4. The resizing handle
  5. The rows and cols attribute

The need for multi-line text inputs

In the preceding chapter, HTML Forms — Input Types, we got to learn about some of the most common types of <input> elements. The one that concerns us for now is <input type="text">, a single-line text input.

A single-line text input, as per its name and also per the detailed newline experimentation that we did with it, can NOT render text containing even a single newline character — the newlines are trimmed off.

Now the question is: What if we want a multi-line text input?

Well, no need to worry, for we have the provision of the <textarea> element for this. A <textarea> element represents a multi-line text input in HTML. This chapter explores everything we need to know regarding this element, so let's get learning.

The <textarea> element

The <textarea> element represents a multi-line text input in an HTML form.

A multi-line text input represents a text input where we can have newline characters.

In practice, <textarea> is almost the same thing as a normal text input rendered by the <input> element — obviously because both represent a text input.

The two main differences lie in:

  • How they treat newline characters.
  • How they get the initial value.

In particular, <textarea> does entertain newline characters in the text input into it whereas <input> (which refers to the type="text" kind) doesn't.

The initial value of an <input> is provided using its value attribute, however for a <textarea>, we rather put the initial value within the element, NOT in the value attribute. That is, the initial value of <textarea> is given as content of the element.

This suggests that the <textarea> element is a container element (comprised of a starting tag, <textarea>, and an ending tag, </textarea>).

Besides these two differences, pretty much everything is the same between <input> and <textarea> — the likes of attributes such as required, placeholder, disabled, and so on.

Even though <textarea> is a container element, we can't have any HTML element within it — only text.

With this basic sense of the element grasped, it's now time to consider an example.

A simple example

Let's say we have a form for asking the user to make a comment as part of a service's general feedback survey (a hypothetical service).

This comment can possibly contain multiple lines of text in it, hence, the most appropriate element to denote it in the form is...you got it...a <textarea>.

Consider the code below where we create such a form in a minimal way:

<form>
   <p>Your feedback</p>
   <textarea name="comment"></textarea>
</form>

Live Example

Go on, open the link above and enter some text into the textarea. Make sure to enter newline characters by pressing the Enter key.

As you enter new lines into the textarea (by pressing Enter), what happens?

Well, as we press Enter, we get a newline character.

A <textarea> input
A <textarea> input containing two lines of text

Recall that this is different from what happens when we do the same thing in an <input type="text"> element — in that case, pressing Enter submits the form when the <input> is part of a <form> element or simply does nothing when it isn't part of a <form>.

This clearly means that to be able to submit a form having just a <textarea>, we definitely need a submit button. Let's add this to our HTML code:

<form>
   <p>Your feedback</p>
   <textarea name="comment"></textarea>
   <br>
   <button>Submit</button>
</form>

Live Example

Great! We can now easily submit the feedback form, thanks to the addition of the button.

Let's add more spice to this example.

A comment is typically meant to be a short block of text, not a whole essay of a thousand words. Limiting the length of the textarea to a certain number of characters at max in our example is, therefore, a sensible idea.

How do you think we can do so? (Hint: It's the same way how we do so in an <input type="text"> element.)

Well, we can leverage the maxlength attribute for this. Going beyond the maxlength limit in a text input simply results in nothing being added to the text input.

For our example, a 200-character limit seems like a good upper bound. In the following code, we apply this bound to the <textarea>:

<form>
   <p>Your feedback</p>
   <textarea name="comment" maxlength="200"></textarea>
   <br>
   <button>Submit</button>
</form>

Live Example

The initial value of a textarea

As stated in the section above, the initial value of a <textarea> element, contrary to a text <input> element, is given by its content.

For example, if we wish an <input type="text"> element, meant for a comment, to begin with the initial value 'Hello', we'll write the following:

<input type="text" name="comment" value="Hello">

The initial value of the text input lands into the value attribute of the element.

However, for a <textarea>, we'll write the following instead:

<textarea name="comment">Hello</textarea>

The initial value rather goes within the <textarea> element, as its content. This is a subtle, but highly important, distinction to keep in mind.

Restating the fact, we can't have any HTML element inside a <textarea>.

The resizing handle

Did you notice the pair of two slanted lines at the bottom-right corner of the rendered output of a <textarea>?

Textarea resizing handle
Textarea resizing handle

What does this represent?

Well, this is a resizing handle, used to change the size of the textarea. By default, the <textarea> element gets this handle.

If we want to remove it, we need to use CSS — particularly, the resize property. The value none for the property indicates that the element is not resizable and shouldn't, likewise, have a resize handle.

Following is an example:

First, let's take a look at a normal <textarea> (note that we've omitted the name attribute for brevity; remember that you should always have it):

<textarea>Hello</textarea>

Now, let's remove the handle using resize:

<textarea style="resize: none">Hello</textarea>

Notice how there isn't any handle displayed on the element, thanks to the application of the resize: none style.

Quite simple, isn't this?

The rows and cols attributes

When working with the <textarea> element, two attributes that you'll notice every now and then are rows and cols. Let's find out what they're meant for.

The rows attribute specifies the number of rows — or more meaningful to say, lines — in the textarea. In effect, this controls the height of the textarea.

When omitted, or when it isn't a positive integer, rows is taken to be "2", i.e. the textarea has a height equivalent to 2 lines of text in it.

Similarly, the cols attribute specifies the number of columns — or more meaningful to say, characters in a line — in the textarea. In effect, this control the width of the textarea.

When omitted, or when it isn't a positive integer, cols is taken to be "20", i.e. the textarea has a width equivalent to almost 20 characters.

Let's take two examples to help understand rows and cols.

Following we have a normal textarea, without any rows or cols (again, we've omitted name for brevity):

<textarea>Hello</textarea>

Due to the omission of rows, it's taken as "2" here; for cols, it's taken as "20".

Now, let's increase the width of this textarea by defining a cols value greater than "20". We'll go with "30":

<textarea cols="30">Hello</textarea>

Due to browser inconsistencies (read the following snippet), we can't say that this textarea is going to span precisely 30 characters. But we can sure say that it's going to be larger in width than a normal textarea (which has an implicit cols value of "20").

Now, let's get to the height of the textarea using rows. We'll take it up to "6":

<textarea cols="30" rows="6">Hello</textarea>

Clearly, the textarea is now larger in width and also height. Perfect!

rows and cols have inconsistent behavior across browsers

It's important to note that rows and cols are NOT strict indicators of the rendered size of a given textarea. They are mere hints.

In fact, across different browsers, the rendered width and/or height of a textarea for the same values of rows and cols might be different.

For example, on Firefox, the actual height of a textarea is one line greater than what is specified by rows. So if we have a textarea with rows="3", the textarea will have a height accounting for 4 lines instead of 3.

HTML can, at times, be very quirky!

Before we end this section, it's crucial to address one point regarding controlling the width/height of textareas.

We already saw how to modify the size of a textarea using the rows and cols attributes. But we can do so using the CSS width and height style properties as well, which we're well-versed with from the previous chapters. (Isn't that so?)

For example, to set the width of a textarea to 300px, we can do the following — no need of setting cols:

<textarea style="width: 300px">Hello</textarea>

On the same lines, to set the height of a textarea to 150px, we can do the following — no need of setting rows:

<textarea style="height: 150px">Hello</textarea>

And this leads us to a very hot question: Should we use rows/cols for specifying the dimensions of a <textarea> or the width/height CSS style properties?

The following snippet answers this.

rows/cols or CSS width/height?

Hmm. Turns out that the norm is to use the latter, i.e. CSS width/height, and that's because these CSS properties allow us to specify the precise dimensions of a textarea.

When you get into web designing, you'll see that quite often when working with forms, for the sake of consistency with the rest of the form controls, textareas have a precise width and/or height.

And the only way we can get a precise dimension is to use CSS. The rows and cols attributes do NOT guarantee a precise width/height, and even if they somehow do, they won't be responsive; CSS, as we already know, can be used to design responsively.

"I created Codeguage to save you from falling into the same learning conundrums that I fell into."

— Bilal Adnan, Founder of Codeguage