form field sizing

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.

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

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.

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

Scripsit Jukka K. Korpela:

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

Oops. My conclusion is not correct, due to a specific looseness
statement in the CSS 2.1 draft:

"CSS 2.1 does not define which properties apply to form controls and
frames, or how CSS can be used to style them. User agents may apply CSS
properties to these elements. Authors are recommended to treat such
support as experimental. A future level of CSS may specify this
further."
http://www.w3.org/TR/CSS21/conform.html#conformance

So browsers may "legimately" ignore all style sheet rules for form
fields, or implement them, or anything between these two extremes.
Moreover, the CSS 2.1 draft does not specify _how_ the properties might
apply to fields; for example, if you set the background of a radio
button, does this mean the thing inside the circle, or a hypothetical
rectangle around it, or both?

The looseness statement is not present in CSS 2.0, which is, unlike CSS
2.1, a "W3C Recommendation", though not recommended by the W3C. In
practice, it's a useful warning.

--
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:QIyrj.294751$H%1.60323
@reader1.news.saunalahti.fi:

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.

--
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 2008-02-10, Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> wrote:

Scripsit Ben C:
[...]
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.

I think most form fields are replaced elements in practice in most
browsers, but they don't have to be.

For example you could do <button> with just some default CSS, something
like border: 2px outset gray, display: inline-block, background-color:
gray, color: black etc.

But it would be much harder to style <option> with CSS.

For example a menu:

<select>
<option>Apples</option>
<option>Oranges</option>
</select>

How would you specify that the contents are supposed to pop up or drop
down, with the selected one visible at the top?

It has to be replaced (at least until enough new CSS3 properties exist
to describe the presentation of menus that users expect).

[...]

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

Yes, and it would be better if styling were never applied to the
contents of replaced elements, instead of a mixed bag of things that
partially work.

For example if I set font-size, font-family, line-height or
background-color on <option> in the example above, Firefox applies them
to the drop-down but not to the normally-displayed other bit.

There's no reason why browsers can't do some form fields as replaced
elements and others not.

Jukka K. Korpela wrote:

This vagueness reflects the fact that browsers have used built-in
routines of underlying systems to implement form fields,

That seems only partially true, or more specifically, they may partially
use built-in routines of underlying systems.

Safari, for example, seems to ignore styling of submit buttons, but it
doesn't just take the default styling of the O/S, either. The Windows
version of Safari styles form fields unlike anything else in my whole
system. Ditto Opera.

--
Berg

Jukka K. Korpela wrote:

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.

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

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.

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

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.

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

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.

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

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

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.

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.

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

Bergamot wrote:

Jukka K. Korpela wrote:
This vagueness reflects the fact that browsers have used built-in
routines of underlying systems to implement form fields,

That seems only partially true, or more specifically, they may partially
use built-in routines of underlying systems.

Safari, for example, seems to ignore styling of submit buttons, but it
doesn't just take the default styling of the O/S, either. The Windows
version of Safari styles form fields unlike anything else in my whole
system. Ditto Opera.

FYI

http://edmullen.net/temp/seamonkey_formbutton.jpg
http://edmullen.net/temp/firefox_formbutton.jpg
http://edmullen.net/temp/opera_formbutton.jpg
http://edmullen.net/temp/safari_formbutton.jpg
http://edmullen.net/temp/ie7_formbutton.jpg

Interesting.

--
Ed Mullen
http://edmullen.net
Is sloppiness in speech caused by ignorance or apathy? I don't know and
I don't care. - William Safire

Ed Mullen wrote:

Bergamot wrote:
Jukka K. Korpela wrote:
This vagueness reflects the fact that browsers have used built-in
routines of underlying systems to implement form fields,

That seems only partially true, or more specifically, they may partially
use built-in routines of underlying systems.

Safari, for example, seems to ignore styling of submit buttons, but it
doesn't just take the default styling of the O/S, either. The Windows
version of Safari styles form fields unlike anything else in my whole
system. Ditto Opera.


FYI

http://edmullen.net/temp/seamonkey_formbutton.jpg
http://edmullen.net/temp/firefox_formbutton.jpg
http://edmullen.net/temp/opera_formbutton.jpg
http://edmullen.net/temp/safari_formbutton.jpg
http://edmullen.net/temp/ie7_formbutton.jpg

Interesting.

As for (from VK's reply elsewhere)

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+

see ...

http://edmullen.net/temp/ie7_fm_largetxt.jpg
http://edmullen.net/temp/opera_fm_largetxt.jpg
http://edmullen.net/temp/safari_fm_largetxt.jpg
http://edmullen.net/temp/sm_fm_largetxt.jpg
http://edmullen.net/temp/ff_fm_largetxt.jpg

All images using current versions of specified browsers on Windows XP Pro.

--
Ed Mullen
http://edmullen.net
Give a person a fish and you feed them for a day; teach that person to
use the Internet and they won't bother you for weeks.

Adrienne Boswell wrote:

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

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

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