Why isn't textarea an input[type="textarea"]?
Why is there an element <textarea> instead of <input type="textarea">?
Maybe this is going a bit too far back but…
Also, I’d like to suggest that multiline text fields have a different type (e.g. “textarea") than single-line fields ("text"), as they really are different types of things, and imply different issues (semantics) for client-side handling.
– Marc Andreessen, 11 October 1993
So that its value can easily contain quotes and <> characters and respect whitespace and newlines.
The following HTML code successfully pass the w3c validator and displays <,> and & without the need to encode them. It also respects the white spaces.
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>Yes I can</title>
</head>
<body>
<textarea name="test">
I can put < and > and & signs in
my textarea without any problems.
</textarea>
</body>
</html>
A textarea can contain multiple lines of text, so one wouldn't be able to pre-populate it using a value attribute.
Similarly, the select element needs to be its own element to accommodate option sub-elements.
It was a limitation of the technology at the time it was created. My answer copied over from Programmers.SE:
From one of the original HTML drafts:
NOTE: In the initial design for forms, multi-line text fields were supported by the Input element with TYPE=TEXT. Unfortunately, this causes problems for fields with long text values. SGML's default (Reference Quantity Set) limits the length of attribute literals to only 240 characters. The HTML 2.0 SGML declaration increases the limit to 1024 characters.
I realize this is an older post, but thought this might be helpful to anyone wondering the same question:
While the previous answers are no doubt valid, there is a more simple reason for the distinction between textarea and input.
As mentioned previously, HTML is used to describe and give as much semantic structure to web content as possible, including input forms. A textarea may be used for input, however a textarea can also be marked as read only via the readonly attribute. The existence of such an attribute would not make any sense for an input type, and thus the distinction.