form field sizing

[Jeff]

I've always set form element sizes by using size on textfields and
rows and cols on textareas.

That's always lead to inconsistencies and a bit of guesswork when you
want a form element to fill a fixed width and you want textfields to be
as wide as textareas.

Now, we can use a bit of CSS to set the width and for textareas also
the height.

Is that a good idea, and if so should I still set size, cols and rows?

Is this widely supported?

It seems like every few years I have to unlearn something.

Jeff

 

[Adrienne Boswell]

I've always set form element sizes by using size on textfields and
rows and cols on textareas.

That's always lead to inconsistencies and a bit of guesswork when you
want a form element to fill a fixed width and you want textfields to be
as wide as textareas.

Now, we can use a bit of CSS to set the width and for textareas also
the height.

Is that a good idea, and if so should I still set size, cols and rows?

Is this widely supported?

It seems like every few years I have to unlearn something.

Jeff

I very rarely set widths for input and textarea via CSS. If no cols and
rows attribute are set for textarea, and the user does not have CSS, the
browser may not render it at all. Those attributes are required by the
specs, see
[http://www.w3.org/TR/html401/interact/forms.html#h-17.7].

You can play around with the size attribute and the cols and rows
attributes to get it to be around the same width. Be aware, however, that
different browsers display widgets differently depending on the browser's
chrome. In Opera, for example, different skins make various sizes of
scroll bars.

 

[Jukka K. Korpela]

Scripsit Jeff:

I've always set form element sizes by using size on textfields and
rows and cols on textareas.

Fine. Just make sure you enlargen them to be sufficient. That's more
than they currently are, probably. Too many textareas are stamp-size.
Too few fields for surname input do not allow Mrs.
Hämäläinen-Virrankoski to enter her name visibly.

That's always lead to inconsistencies and a bit of guesswork when
you want a form element to fill a fixed width and you want textfields
to be as wide as textareas.

Then stop wanting such things.

The widths are for convenient input, not for the author's esthetic eye.

Now, we can use a bit of CSS to set the width and for textareas also
the height.

That doesn't mean we should.

Is that a good idea, and if so should I still set size, cols and
rows?

Consider the CSS Caveats:
http://www.cs.tut.fi/~jkorpela/css-caveats.html

Besides, the cols and rows attributes are required in a textarea element
by HTML syntax. And you should always set the size attribute for a
single-line text input field, since its default value is unspecified.

It seems like every few years I have to unlearn something.

Indeed. But that's a different story.

 

[Adrienne Boswell]

Besides, the cols and rows attributes are required in a textarea element
by HTML syntax. And you should always set the size attribute for a
single-line text input field, since its default value is unspecified.

Before I posted my answer I was Googling for your thoughts on this, since
you have replied to something like this before. Thank you.

 

[VK]

Before I posted my answer I was Googling for your thoughts on this, since
you have replied to something like this before. Thank you.

It is strange that no one posted so far the most valuable advise:
always define font-size for INPUT, TEXTAREA and SELECT elements. I
mean not pixel size but some relative size, in the most common case
FORM INPUT {
font-size: 1em;
}
FORM TEXTAREA {
font-size: 1em;
}
FORM SELECT {
font-size: 1em;
}
If there is not relative font-size set, in both IE6 and IE7 form
elements will be excluded for font (IE6) or screen (IE7) sizing on say
Ctrl+
That means that no matter what "augmentation" is set, it will be a big
page content with the same small form elements (and text in them) in
it. The most ugly things happen with buttons, where the button size
yet growths but button label remains puny. I would rate this design
oops #2 right after #1 (box model errors).

 

[Jeff]

Scripsit Jeff:


Fine. Just make sure you enlargen them to be sufficient. That's more
than they currently are, probably. Too many textareas are stamp-size.
Too few fields for surname input do not allow Mrs.
Hämäläinen-Virrankoski to enter her name visibly.

Oddly, my default text field is 30, which is more than that. And I
usually make textareas 55 x 4 sometimes with an auto lengthen.

The trouble is that you usually want textareas to take up the max
width and generally you have to downsize them to due to width
requirements on some browser. That's why I thought style="width: 100%"
would be nice. I'll have to read the caveats later to see why that isn't
so.

Jeff

 

[Jukka K. Korpela]

Scripsit Jeff:

Oddly, my default text field is 30, which is more than that.

Your 30 is a reasonable value. I wrote "too few".

And I usually make textareas 55 x 4 sometimes with an auto lengthen.

Auto lengthen?

Anyway, 4 is far from sufficient for any normal textarea. How would you
like to use a word processor with a document canvas of that size? It's
frustrating to see less than a paragraph of what you have written so
far. Such a size is a message about the value assigned to user input by
the form designer and about the amount of text expected. That is, it
says: don't bother sending us anything that matters much.

The trouble is that you usually want textareas to take up the max
width

Do I? I don't think that a screen-wide textarea is convenient, and it
surely looks odd on most screens. A width of 55 characters or so (maybe
somewhat more) is generally suitable. The problem with it is that it
forces horizontal scrolling in a narrows window. But I don't think it's
a very serious problem.

and generally you have to downsize them to due to width
requirements on some browser.
Pardon?

That's why I thought style="width: 100%" would be nice.

Not really as nice as one might expect.

Even if you set font-size: 100% and something like font-family: Cambria,
Georgia, serif (making typing reasonably convenient), a textarea with
size="55" fits into half of the width of a fairly normal screen. This
should be acceptable, and anything wider probably doesn't significantly
improve the ease of writing.

It would be more relevant to make the _height_ as large as possible (on
CSS-enabled browsers), but there's no simple way to do that.

 

[Jeff]

Scripsit Jeff:


Your 30 is a reasonable value. I wrote "too few".


Auto lengthen?

Javascript. I never was fond of scrollbars on textareas, so on textareas
that could need to be very long (or not at all), I simple add a couple
rows when needed. Been doing it for 4 or 5 years. As far as I know, I'm
the only one that does that. No complaints so far.

Anyway, 4 is far from sufficient for any normal textarea.

Actually I find most textarea needs are far less than that.


How would you

like to use a word processor with a document canvas of that size? It's
frustrating to see less than a paragraph of what you have written so
far. Such a size is a message about the value assigned to user input by
the form designer and about the amount of text expected. That is, it
says: don't bother sending us anything that matters much.


Do I? I don't think that a screen-wide textarea is convenient, and it
surely looks odd on most screens. A width of 55 characters or so (maybe
somewhat more) is generally suitable. The problem with it is that it
forces horizontal scrolling in a narrows window. But I don't think it's
a very serious problem.

Aesthetics my boy. Edges should line up. Set a width for you form,
either in % or pixels and the right edges should align. Just as the left do.

Pardon?

Whether you like it or not, most sites have fixed width sections, and
most flunkys like myself have to adhere to what the "boss" wants.

Lets say you have a form that can be 600px wide. Now since that's
tabular data you put that in a table, the left column would be the
labels (right aligned) and the right would be the text fields and
textareas. Since some browsers will have a X number textarea wider than
others you take the set it a little smaller so it doesn't blow out the
container width.

Not really as nice as one might expect.

Even if you set font-size: 100% and something like font-family: Cambria,
Georgia, serif (making typing reasonably convenient), a textarea with
size="55" fits into half of the width of a fairly normal screen. This
should be acceptable, and anything wider probably doesn't significantly
improve the ease of writing.

I've never tried that, I'll give it a go.

It would be more relevant to make the _height_ as large as possible (on
CSS-enabled browsers), but there's no simple way to do that.

See above.

Jeff

 

[Jukka K. Korpela]

Scripsit Jeff:

I never was fond of scrollbars on textareas, so on
textareas that could need to be very long (or not at all), I simple
add a couple rows when needed. Been doing it for 4 or 5 years. As far
as I know,
I'm the only one that does that.

Now you're explaining something that you yourself characterize as
unique, and later you're telling that you work with px dimensioned
layout as so many others. Somehow this does not add up.

No complaints so far.

Web users don't complain. They just go away, or don't get the job done,
or start hating the site.

Actually I find most textarea needs are far less than that.

I'm speechless. See above. It's an insult to users to ask them to send
feedback, or add any comments, and allocate the ridiculous four lines
for it.

Aesthetics my boy. Edges should line up. Set a width for you form,
either in % or pixels and the right edges should align. Just as the
left do.

That's poor usability, since the lengths of fields don't act as clues
any more.

 

[Adrienne Boswell]

Anyway, 4 is far from sufficient for any normal textarea. How would you
like to use a word processor with a document canvas of that size? It's
frustrating to see less than a paragraph of what you have written so
far. Such a size is a message about the value assigned to user input by
the form designer and about the amount of text expected. That is, it
says: don't bother sending us anything that matters much.

I know someone who thinks _2_ is perfect. Not only that, this person
insists on only 2 lines, and placing content on the form saying something
like "only 2 lines permitted". I have explained that lines is not a good
measurement, for many reasons, until I am blue in the face.

 

[Jeff]

Scripsit Jeff:


Now you're explaining something that you yourself characterize as
unique, and later you're telling that you work with px dimensioned
layout as so many others. Somehow this does not add up.

Now, you've snipped that without noting and removed the meaning in the
process.

Web users don't complain. They just go away, or don't get the job done,
or start hating the site.


I'm speechless. See above. It's an insult to users to ask them to send
feedback, or add any comments, and allocate the ridiculous four lines
for it.

Surely you realize that there are many other uses for textareas? You
were just talking about how a textfield is often insufficient.

My default is either 4 or 5. Making forms is a typical thing to do, so
like any programmer would, I have a utility where you input the field
names, label, types... and that spits out an editable form with the
database table code. Sizes can get fine tuned from there and styles
added. Perhaps you haven't seen enough live data to get a feel for what
web surfers do... Or that feedback is only one use, and certainly you
would have more than 4 rows for such a textarea. I certainly don't spend
my time writing contact forms and I know of no one else who does. But if
you have a typical form with perhaps a half dozen or so of textfields,
options and textareas you don't want to make all the textareas so long
that the page scrolls and scrolls and scrolls, that is discouraging to a
user. You should be able to see the end.

Jeff

That's poor usability, since the lengths of fields don't act as clues
any more.

Well, I don't understand how you could come the end of a textarea and
not know you were there.

 

[Adrienne Boswell]

Well, I don't understand how you could come the end of a textarea and
not know you were there.

Textareas don't have an end. That's why there have been many client
side scripts written to a) alert the user how many characters have been
entered, b) stop the user from inputting anymore characters.

Input on the other hand, is different. If the author has put in
maxlength="20" and size="50" (or styled it such), the user has no way of
knowing the maximum length _before_ they start typing, the field just
will not take anymore characters, and
a) the user is confused
b) the user has not noticed and has put in the wrong information.

If I make a input element have maxlength, I set the size to be the same.
If there is a textarea involved, say 50 cols, I usually set input
element size to 50 also, so their widths are _about_ the same. But, in
that situation, if a field's length is 40 characters, then I still set
the input element's size to 40 and maxlength to 40.

 

[Jeff]

Textareas don't have an end. That's why there have been many client
side scripts written to a) alert the user how many characters have been
entered, b) stop the user from inputting anymore characters.

Ah, I didn't know that's what we were talking about.

Input on the other hand, is different. If the author has put in
maxlength="20" and size="50" (or styled it such), the user has no way of
knowing the maximum length _before_ they start typing, the field just
will not take anymore characters, and
a) the user is confused
b) the user has not noticed and has put in the wrong information.

If I make a input element have maxlength, I set the size to be the same.

I'm a little confused about the real value of a maxlength. I suppose it
is to keep customers from entering beyond the database field size limit,
but if you are not indexing on a field there's little reason not to make
the field much larger. As far as textarea limits why set a limit at all,
it's rare to index that at all so there's little reason there not to
put it into something like a mysql TEXT.

Perhaps I'm missing something here.

Now, who was talking about setting font-sizes on form fields, I
can't find the post now and that sounds interesting.

If there is a textarea involved, say 50 cols, I usually set input
element size to 50 also, so their widths are _about_ the same. But, in
that situation, if a field's length is 40 characters, then I still set
the input element's size to 40 and maxlength to 40.

Why the max length? I don't remember the last time I set that, so
maybe I'm missing a design or useability consideration.

Jeff

 

[Chaddy2222]

   Ah, I didn't know that's what we were talking about.





I'm a little confused about the real value of a maxlength. I suppose it
is to keep customers from entering beyond the database field size limit,
but if you are not indexing on a field there's little reason not to make
the field much larger. As far as textarea limits why set a limit at all,
it's rare to index that at all so  there's little reason there not to
put it into something like a mysql TEXT.

   Perhaps I'm missing something here.

   Now, who was talking about setting font-sizes on form fields,   I
can't find the post now and that sounds interesting.


   Why the max length? I don't remember the last time I set that, so
maybe I'm missing a design or useability consideration.

   Jeff

Nah.
I would not use that eather.
Unless you want to restrict what a user can place in the field (such
as only allowing them to place number), in a field where you want
them to place an amount.

 

[Adrienne Boswell]

Gazing into my crystal ball I observed Chaddy2222 <spamlovermailbox-
(e-mail address removed)> writing in (e-mail address removed):

Maxlength for input elements, sometimes. For example, a database field
is 20 characters. You don't want the user to put in 21 characters, so
you set it to 20. That way, you know that you are going to get 20
characters server side. Of course, you are going to check server side
anyway - but it's a client side method that does not rely on client side
script.

Nah.
I would not use that eather.
Unless you want to restrict what a user can place in the field (such
as only allowing them to place number), in a field where you want
them to place an amount.

Contents of a field either has to be checked server side, or with client
side script. Maxlength does not affect that at all.