Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
May 10, 2006, 9:07 pm
rate this thread
The w3schools HTML tag reference for <textarea>
says that the attributes 'cols' and 'rows' are REQUIRED attributes for
the textarea tag. Looking at the HTML 4.01 specification I see this, too.
What I'm wondering is - 'cols' & 'rows' determines the height & width of
a textarea. So shouldn't that be something that is handled by CSS
instead? What would be the practical consequence of leaving out both
attributes and setting the height & width with CSS (I know it works -
I've tried it, but I'm wondering if there might be something I'm missing)
Gazing into my crystal ball I observed Tony
If CSS is not available there could be issues. For example, if your
textarea is quite large, say 300px x 300px, without styling, the widget
is very small causing the user to have to scroll a lot.
Adrienne Boswell at Home
Arbpen Web Site Design Services
Please respond to the group so others can share
So, surprisingly, the w3schools site hasn't messed up this simple thing.
It is generally useless as a _reference_, no matter what one might think
about the _pedagogical_ suitability of some material there. Personally,
I'd prefer learning things from a source that has got them mostly right,
even if some other source might present them more reasably.
The visible height and width, yes, though not quite consistently. I just
noticed that IE 7 beta uses an area that is 19 characters wide when
using the default (monospace) font there, when I set cols="19". Maybe
this is so because the vertical scroll bar occupies roughly the width of
In some other universe, perhaps. This is not pure presentation, however.
The visible size of the field conveys a message about the amount of
expected typical input (so that authors can use a stamp-size textarea in
feedback forms to express how much feedback they want :-) ). There is no
way in HTML to express the kind of expected input (say, an address, a
short letter, or a novel), so the rows and cols attributes work as
(very) implicit indicators.
Perhaps it "works" for some value of "works". Have you tried it in all
browsers with all settings? Remember that HTML specifications do not
mandate the processing of invalid documents, so you cannot blame anyone
but yourself if Mozilla 2.0 or IE 8.0 decides to ignore <textarea>
elements without the required attributes.
What happens in practice at least in most browsing situations is that
browsers use some default values. IE 7 beta seems to use rows="2"
cols="20". This is a strong reason for not omitting the attributes: the
effect is generally browser-dependent and typically a quite small
textarea, with dimensions that are hardly suitable for anything that you
could meaningfully use <textarea> for.
You do realize, don't you, that CSS is for optional presentational
suggestions? When CSS is disabled, or even unsupported by a browser, the
dimensions of <textarea> are determined by the rows and cols attributes
(or their browser-dependent default values).
Considering the utility of textarea, it's rather an unloved creature,
without a real sense of belonging. When the web was first developed,
telnet and email were almost an afterthought. And yet they became
a primary underpinning of the web - people at the time didn't realize
how compelling the communication aspect was. Similarly with
textareas, which were intended to be used strictly to get some input
from the user. Thus, the logic saying that content of a textarea
is not considered part of its innerHTML, seems, in retrospect, not
so very clever.
So the thing about cols is that it serves a dual purpose. The
first is that rows and cols are a default way to specify the size of
the textarea, but that is overridden by CSS. Frankly, requiring cols
and rows is another silly thing which requirement may finally be
For the second purpose, consider a chunk of text plopped into a
textarea. It may be that what is important (from the web page's
point of view) is the original/intended formatting of the text,
regardless of what viewing limitations the textarea imposes, or
it may be that what is important is the way the user actually
sees what is in the textarea.
For example, if the text started out as:
The quick brown fox jumped over the lazy dog.
and the user sees, in the textarea:
The quick brown fox
jumped over the lazy
what should be submitted to the server?
To accommodate this the textarea takes the settings
wap=soft (default) or wrap=hard. If the textarea has
wrap=soft set, then what is submitted reflects the underlying
text whereas with wrap=hard the server gets the a string
corresponding to the viewed text. And this is reasonable.
But then the proposal above becomes completely
silly saying that cols is to used in determining where to
add the inserted newlines. In other words, rather than
submitting what the user sees, or what the underlying
text is, a third version that is not related to either of these
is submitted. And the worst part about that is that
it could just as well be (indeed, should be) determined
on the server. There is no architectural reason that I
can see for having it client side - it serves no purpose,
and imposes client side computation for something that
is server side responsibility (someone could easily alter
the .wrap on the submitting textarea, for example)
Fortunately, the proposed new spec is not totally lame on
this point. It begrudgingly says that if you don't specify
cols with wrap=hard, then the actual (observed) wrapping
should be used (But then it says that that would be
silly and defeat the purpose of client-side wrapping,
without mentioning what that purpose is).
Unfortunately, in the current implementation of Firefox,
if you don't specify cols when wrap is set to hard, then
you will get a default wrap at 20. The conclusion is that
if you have wrap=hard and use CSS to set the size of
the textarea, then the string submitted for the textarea
will probably not be well related to what the user enters.
Csaba Gabor from Vienna
Note 1: There is another wrap setting, to the tune of
wrap=off, but this is essentially syntactical sugar for
saying: wrap=soft and have horizontal scroll on overflow.
It doesn't change what gets submitted.
Note 2: Textareas fonts don't have to be fixed width.
In this case a well implemented textarea
element wraps when there isn't anymore room (as
opposed to at a fixed character count). I let you
figure out which browsers actually implement it well.
I'm an absolute novice when it comes to CSS, but I was very pleased to
find that it could be used to make a textarea scale to fit the width of
the browser window:
<TEXTAREA NAME=SAYING WRAP=VIRTUAL style="width:100%;height:180"></TEXTAREA>
Up until I discovered this I was always bothered by the fact that I
either had horizontal scrollbars or wasted space on the right side of
The HTML above, by the way, was intended only for my own use. In the
page where it occurs, I'm the only person who gets this particular input
- » How to call a simple perl script from HTML without need of HTTPS but simple HTTP ?
- — Next thread in » HTML Authoring Forum