468,134 Members | 1,394 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,134 developers. It's quick & easy.

<textarea> cols & rows

The w3schools HTML tag reference for <textarea>
http://www.w3schools.com/tags/tag_textarea.asp
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)
May 10 '06 #1
6 28315
Gazing into my crystal ball I observed Tony
<to****@dslextreme.WHATISTHIS.com> writing in
news:12*************@corp.supernews.com:
The w3schools HTML tag reference for <textarea>
http://www.w3schools.com/tags/tag_textarea.asp
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)


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
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

May 11 '06 #2
Tony wrote:
The w3schools HTML tag reference for <textarea>
http://www.w3schools.com/tags/tag_textarea.asp
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.
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.
What I'm wondering is - 'cols' & 'rows' determines the height & width of
a textarea.
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
one character.
So shouldn't that be something that is handled by CSS
instead?
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.
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)


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).
May 11 '06 #3
Tony wrote:
The w3schools HTML tag reference for <textarea>
http://www.w3schools.com/tags/tag_textarea.asp
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)


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
obsoleted:
http://www.whatwg.org/specs/web-form...k/#extensions1

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
dog

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.

May 12 '06 #4
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 page.

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
area.
--
Steve Swift
http://www.ringers.org.uk
May 18 '06 #5
Steve Swift <St*********@uk.ibm.com> scripsit:
<TEXTAREA NAME=SAYING WRAP=VIRTUAL
style="width:100%;height:180"></TEXTAREA>


Conforming browsers ignore the declaration height:180, since its value is
syntactically incorrect. You probably meant height:180px, but you should
actually use something more flexible such as height:15em.

(This is actually a stylesheet matter, not about HTML.)
May 18 '06 #6
> you should actually use something more flexible such as height:15em.

Thank you for that correction.

--
Steve Swift
http://www.ringers.org.uk
May 19 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Dennis Allen | last post: by
16 posts views Thread by Martin Trautmann | last post: by
11 posts views Thread by Les Paul | last post: by
7 posts views Thread by =?ISO-8859-1?Q?=22=C1lvaro_G=2E_Vicario=22?= | last post: by
27 posts views Thread by didacticone | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.