The TEXTAREA element indicates a multi-line text entry field. The contents
between the beginning and end TEXTAREA tags represent the initial contents
of the field in the browser.
Description:
This is a method of giving access/focus to an active HTML element using
a keyboard character. This is a common GUI paradigm also known
as a "keyboard shortcut" or "keyboard accelerator"
A single character is used as the value of this attribute. In addition,
a platform-dependent key is usually used in combination with the
ACCESSKEY character to access the functionality of the active field.
Values:CDATA.
[A single, case-insensitive character from a browser's character set.]
Description:
This is a stand-alone attribute which indicates the element is
initially non-functional. Disabled form elements should not be submitted
to the form processing script.
Description:
This is an SGML Document Access
(SDA) attribute. SDA attributes are designed to transform HTML (and
other SGML-based documents) to the ICADD
DTD - which is used in creating accessible documents for users with
visual disabilities (rendering in Braille, large print, speech
synthesis, etc.) The attribute value specifies the name of the element
to convert this element to in the SDA element group (in this case the
'Para' element - "paragraph".)
Description:
This is an SGML Document Access
(SDA) attribute. SDA attributes are designed to transform HTML (and
other SGML-based documents) to the ICADD
DTD - which is used in creating accessible documents for users with
visual disabilities (rendering in Braille, large print, speech
synthesis, etc.) The attribute value specifies content to be added
BEFORE the original element content (in this case the string
"Input Text -- #AttVal(Name): ") when the SDA document is rendered (SDA
also allows attributes and values from the original element to be used
in the new SDA element where necessary.) "#AttVal(Name)" refers to the
TEXTAREA NAME attribute if present.
Description:
"Tabbing" is a method of giving access/focus to an active HTML
element using a standard keyboard sequence. All the active elements in a
document can be cycled through using this sequence (ex: Windows TAB key.)
The order of the active elements in this cycle is usually the order they
occur in the document, but the TABINDEX attribute allows a different order
to be established. The use of this attribute should create the following
tabbing order cycle if the browser supports the attribute:
Active elements using the TABINDEX attribute with positive integers are
navigated first. Low values are navigated first.
Active elements not specifying any TABINDEX attribute
Those elements carrying a DISABLED attribute or using negative TABINDEX
values do not participate in the tabbing cycle.
Description:
This attribute indicates word-wrapping behavior for display and submitted
data from the Textarea field.
Values: Off - No word wrapping to the
textarea window occurs - if lines extend beyond the width of the textarea
they will not wrap. Lines are sent exactly as typed.
DEFAULT in Netscape Soft - Text is displayed with
wordwrapping to the textarea enabled, but these wrap points are not
transmitted upon submittal as returns/linefeeds.
DEFAULT in Internet Explorer Hard - Text is displayed with
wordwrapping to the textarea enabled, and these wrap points are preserved
upon submittal.
Example
<form>
<textareaname="foo"
rows="3"
cols="40">
Default TEXTAREA value goes here
</textarea>
</form>
The TEXTAREA element appears to have been supported in Mosaic 2.0
Alpha 1, but in testing it directly, the feature seemed to be mostly
broken. The Alpha 2 release brought behavior closer to what is considered
'normal' for current browsers, so I chose that release as the first
"supported" version.
The Internet Explorer online HTML reference listed support for an additional method
of specifying a TEXTAREA in the 3.0 version timeframe using the
<INPUT TYPE=TEXTAREA> element. It used all the same attributes as the
TEXTAREA element, but was not a container element. A VALUE attribute was used
to take the place of the container behavior of TEXTAREA. Even though the
reference stated that IE supported this, no version I have ever found actually
DOES support it.
The documentation for Netscape 2.0 lists two interesting values for the WRAP
attribute: PHYSICAL and VIRTUAL. It does appear to support these
values after a strange fashion - they are both treated exactly the same way as
SOFT (which is not Netscape's default value for this attribute.) Interesting to
note also that BOTH Microsoft and Netscape have each listed PHYSICAL and VIRTUAL
in one of their references, even though these values have never really worked.
Values of SOFT and HARD HAVE worked for this attribute since Netscape
version 2.0 and Internet Explorer 4.0.
See http://wp.netscape.com/assist/net_sites/new_html3_prop.html
for the Netscape reference that lists VIRTUAL and PHYSICAL (Microsoft's reference
listing VIRTUAL/PHYSICAL has since been taken down.)
Internet Explorer 5.0 briefly supported an element in its beta 2 release
called HTMLAREA. This element was very much like TEXTAREA, but it allowed
rich HTML markup to be included and manipulated in the editing control area. This
content, along with its rich markup, would be passed to the form's processing
script. Support for this element was retracted in the final version of Internet
Explorer 5.0.
[Test]
Netscape 4+ allows some Character-level formatting to be applied to the
contents of this form field. These physical formatting elements (along with
virtual formatting elements that are rendered identically, such as
EM and I) apply to this form field: I, S, STRIKE, SUB, SUP, BIG, SMALL,
FONT SIZE and FONT FACE.
The DIR="RTL" attribute right aligns the content of TEXTAREA elements
WITHIN the form field, not the element itself relative to the
viewport as it does for other elements.
[Test]
Opera 4: If you use the HEIGHT and WIDTH attributes, the ROWS and COLS
attributes are ignored.
[Test]
Opera 5/6: Using the DISABLED attribute still sends the name/value pair
for the element to the form processing script. It should not do this.
[Test]
Mozilla/Netscape 6+ does not calculate the rows and cols attributes correctly.
If you specify a TEXTAREA with rows=10 and cols=20, you will get a control
that is about 22 cols/characters wide by 11 rows/characters. It appears
that the difference is pretty constant - generally about 3 extra cols wide
and one extra row tall. The reader that pointed this out to me also noted it
appears that Mozilla is allowing space for the scroll bars in addition to
the rows/cols you specify, even though they are not present by default.
(bugzilla #33654.)