form field sizing

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

Gazing into my crystal ball I observed Jeff <jeff (AT) spam_me_not (DOT) com> writing
in news:13qr0d414ngr535 (AT) corp (DOT) supernews.com:

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/interac...s.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.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

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.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Gazing into my crystal ball I observed "Jukka K. Korpela"
<jkorpela (AT) cs (DOT) tut.fi> writing in news:csmrj.294458$GG1.83526
@reader1.news.saunalahti.fi:

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.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

On Feb 9, 10:28 pm, Adrienne Boswell <arb... (AT) yahoo (DOT) com> wrote:

Gazing into my crystal ball I observed "Jukka K. Korpela"
jkorp... (AT) cs (DOT) tut.fi> writing in news:csmrj.294458$GG1.83526
@reader1.news.saunalahti.fi:

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.

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).

On 2008-02-09, Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> wrote:
[...]

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

One thing you say there is "CSS Support varies [...] For form fields,
many CSS properties are often ignored by browsers".

It's not really lack of "support" for anything. Any CSS styling you can
do on form fields at all is a bonus. As far as the CSS 2.1 specification
is concerned, buttons, textareas, etc., are replaced elements. You
shouldn't expect to be able to style them with CSS properties at all,
although most browsers do let you set a few things.

Jukka K. Korpela wrote:

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.

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

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.

Scripsit Jeff:

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.

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.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Scripsit Ben C:

On 2008-02-09, Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> wrote:
[...]
Consider the CSS Caveats:
http://www.cs.tut.fi/~jkorpela/css-caveats.html

One thing you say there is "CSS Support varies [...] For form fields,
many CSS properties are often ignored by browsers".

It's not really lack of "support" for anything.

It depends, though I see your point, and form field oddities could also
be characterized as belonging to the caveat listed last (CSS specs are a
moving target).

As far as the CSS 2.1
specification is concerned, buttons, textareas, etc., are replaced
elements. You shouldn't expect to be able to style them with CSS
properties at all, although most browsers do let you set a few things.

A replaced element (what I strange term) is "an element whose content is
outside the scope of the CSS formatting model", but are form fields
replaced elements? The CSS 2.1 draft mentions, at
http://www.w3.org/TR/CSS21/conform.h...placed-element
images, embedded objects, and applets as examples of replaced elements.
Form fields are not mentioned, even though they are surely more common
than applets.

This vagueness reflects the fact that browsers have used built-in
routines of underlying systems to implement form fields, and such
routines are often immune to anything you might say in CSS: there's no
way to pass formatting instructions to them. This has slowly changed.

We could say that an <input> element is a replaced element, so a browser
need not and must not apply any CSS rules to its content (since that
content is "outside the scope of the CSS formatting model"). But that's
not what browsers generally do these days. They treat <input> as
something with content that can be affected via CSS, and then they
cannot claim that <input> is a replaced element. Thus, it becomes a
matter of coverage of support: some properties are supported, some are
not.

There's no "half-replaced element" concept in CSS, so any _partial_
support to CSS features for, say, <input> elements violates CSS
specifications (or "specifications"). In the CSS 2.1 draft, the
conformance clause allows properties to be ignored but only due to
_device_ restrictions:
"The inability of a user agent to implement part of this specification
due to the limitations of a particular device (e.g., a user agent cannot
render colors on a monochrome monitor or page) does not imply
non-conformance."
http://www.w3.org/TR/CSS21/conform.html#conformance

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jukka K. Korpela wrote:

Scripsit Jeff:

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.

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?

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.

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.

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.

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

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.

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.

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