128
xhtml forms
you are here
�
607
there are no
Dumb Questions
Q:
What’s the difference between a
text <input> and a <textarea>?
A:
You want to use a text <input> for
entering text that is just a single line, like
a name or zip code, and a <textarea> for
longer, multi-line text.
Q:
Can I make the submit button say
something other than “Submit”?
A:
Yes, just put a value attribute in the
element and give it a value like “Order Now”.
You can also use the value attribute of text
input to give that input some default text.
Q:
Is there a limit to how much
text I can type into a text <input> or a
<textarea>?
A:
Browsers do place a limit on the
amount of text you can type into either a
text <input> or a <textarea>; however, it’s
usually way more than you’d ever need to
type. If you’d like to limit how much your
users can type into a text <input>, you can
use the maxlength attribute and set it to a
specific number of characters. For example,
maxlength=”100” would limit users to typing
at most 100 characters. However, for a
<textarea>, there is no way with XHTML to
limit how much your users can type.
Q:
I still don’t get how the names get
matched up with the form data.
A:
Okay, you know each form element
has a unique name, and you also know
that the element has a corresponding value.
When you click the submit button the
browser takes all the names along with
their values and sends them to the server.
For instance, when you type the zip code
“90050” into a text <input> element with the
name “zip”, the browser sends “zip = 90050”
to the server when the form is submitted.
Q:
How does the Web application
know the names I’m going to use in my
form? In other words, how do I pick the
names for my form elements?
A:
Good question. It really works
the other way around: you have to know
what form names your Web application
is expecting and write your form to match
it. If you’re using a Web application that
someone else wrote, they’ll have to tell
you what names to use, or provide that
information in the documentation for the
application. A good place to start is to ask
your hosting company for help.
Q:
Why doesn’t the <option>
element have a name attribute? Every
other form element does.
A:
Good catch. All <option> elements
are actually part of the menu that is created
by the <select> element. So, we only really
need one name for the entire menu, and
that is already specified in the <select>
element. In other words, <option> elements
don’t need a name attribute because the
<select> has already specified the name for
the entire menu. Keep in mind that when
the form is submitted, only the value of the
currently selected option is sent along with
this name to the server.
Q:
Didn’t you say that the name for
each form element needs to be unique?
But the radio <input> elements all have
the same name.
A:
Right. Radio buttons come as a set.
Think about it: if you push one button in, the
rest pop out. So, for the browser to know
the radio buttons belong together, you use
the same name. Say you have a set of radio
buttons named “color” with values of “red”,
“green”, and “blue”. They’re all colors, and
only one color can be selected at a time, so
a single name for the set makes sense.
Q:
What about checkboxes? Do they
work like radio buttons?
A:
Yes; the only difference is that you
are allowed to select more than one choice
with a checkbox.
When the browser sends the form data to
the server, it combines all the checkbox
values into one value and sends them
along with the checkbox name. So, say
you had “spice” checkboxes for “salt”,
“pepper”, and “garlic”, and you checked them
all; then the server would send “spice =
salt&pepper&garlic” to the server.
Q:
Geez, do I really need to know
all this stuff about how data gets to the
server?
A:
All you need to know is the names
and types of the form elements your Web
application is expecting. Beyond that,
knowing how it all works sometimes helps,
but, no, you don’t need to know all the gory-
behind-the-scenes details of what is being
sent to the server.
