Module 4 Lecture Notes 1
Module 4 Lecture Notes 1
HTML Forms
Overview
The HTML Forms capability allows the client to interact with and send user entered information to the web server
in a variety of ways. Using Forms a user can enter textual data or make selections from a set of choices in various
ways.
Once the data is entered by the user, the user can then send the data to the server for processing, usually via
some type of server-side script. The server then processes the request, perhaps using the user's input for entry or
access to some database. The server then needs to reply to the form input. That reply must be an HTML
document, which then is rendered in the browser. The following diagram illustrates this transaction:
Forms can also be processed by client-side scripts, for example, to check user input for accuracy before it is sent
to the server. This validation is typically done using JavaScript, so we will cover that aspect in a future module.
HTML allows a rich variety of input methods. Users can enter information via the following methods:
• Text Input
• Checkboxes
• Radio Buttons
• Menus
• Buttons
• File Select
The FORM element has two important attributes, ACTION and METHOD.
1
The ACTION attribute of the FORM element contains the URL of the server script that will process the form.
The METHOD attribute can be either "GET" or "POST", which determines how the information contained in the
form is packaged for transmission to the server script. METHOD can only be one of these two values; any other
value is incorrect, and may result in unpredictable results.
"GET"
If the METHOD is "GET" and the action is an HTTP URL, the user agent takes the value of ACTION, then
appends a `?' to it, and then appends the form input as a sequence of name=value pairs separated by "&". The
browser then traverses the link to the URL preceding the "?".
In this case, the user can bookmark the form along with the input, (for example to re-invoke a common search).
Go to the URL below and fill in some values for a pizza order, then submit the form. Don't worry about the
resulting page (it might look just like the original form) – but look at the URL in the address bar. You should then
note the "?" that follows the URL, and see if you can interpret your entry. Some of it may be hard to read, but you
should recognize some fragments of your entry. If you wanted to order this same pizza at some time in the future,
you could bookmark this page, and submit it anytime. (Of course, this sample doesn't really order pizza!)
Using this method, you can only send text data, not binary, and the length of data which can be sent is limited.
Also, data is slightly less secure, since the URL can be viewed by an onlooker.
"POST"
If the method is "POST" and the action is an HTTP URL, the user agent conducts an HTTP "POST" transaction
using the value of the ACTION attribute and a message containing the user information.
If the method is "POST", the user cannot bookmark the form along with the input, because the form input is not
part of the URL. However, a user can send binary as well as text data, and the length of data is unlimited. Data
can be more secure, since data can't be viewed on the URL line or in the HTTP header, and the data can be
encrypted.
The above example link is the same as the first; the only difference is the METHOD attribute is set to POST rather
than to GET. If you enter your pizza choice, and submit your form, you will note that your information is now not
part of the URL. However, the data you entered did get to the server as the resulting page shows.
Why are there two methods for submitting data to the server from a form?
The GET method was there first, and based on the aforementioned limitations, another method was needed.
Hence the POST method was added. But, for simple, small text-based forms the GET method is more than
satisfactory, and the ability to bookmark the form input is a nice capability that is not present with the POST
method. Since both have their advantages, both methods will continue to exist within HTML forms.
2
The INPUT Element
The INPUT element is used for most types of form input. The TYPE attribute of this element is used to determine
the type of input. Each INPUT element should have a NAME attribute, which will be passed to the server when
the form is submitted.
Other INPUT attributes (some are required; some are optional, depending on the TYPE attribute):
Text Input
A simple text box which only allows a single row of text to be entered is created by specifying a type of "text" for
the input type. The SIZE attribute specifies the width of the text box. Note that this does not limit how much the
user can enter, but it represents how big the text box will display on the browser window. The width will be in
characters for monospace fonts, and in ems for proportional fonts. The default for the SIZE attribute is 20.
The MAXLENGTH attribute, if set, limits the text entry to MAXLENGTH characters in the text box. Text will scroll if
SIZE < input value <= MAXLENGTH. MAXLENGTH is limited to 1024 characters.
For example:
This would result in a 20 character text box rendered on the display, and the user would be able to type in at most
30 characters. The NAME attribute will be set to the user entry and passed to the server. For example, if the user
enters "Brian", it will be sent to the server as:
firstname=Brian
Setting the TYPE to "password" is the same as "text", except the browser will display the entered text such that it
is hidden from someone viewing the browser. (Most browsers echo the input as asterisks.) However, the entered
text traverses the network as clear text, if you send it over regular HTTP. So, you especially want to avoid this
with METHOD="get", since the entered password can be fairly easily viewed in the URL (and yes, you will see the
entered password, and not the asterisks.)
Checkboxes
Checkboxes are on/off switches that may be toggled by the user. They are created by using the INPUT element
with TYPE="checkbox". A set of checkboxes within a form may have the same NAME; they can be discriminated
by having unique VALUES. However, server-side processing is easier if NAMEs are unique.
A user may select several, all, or none of an associated set of checkboxes. A web designer can initially set
checked boxes using the CHECKED attribute. To label each check box, you should supply a text string outside
the INPUT element to label the box. Only checked boxes are sent to the server.
For example:
3
If the user checked both of the boxes, the following would be sent to the server:
pepperoni=Y&sausage=Y
Radio Buttons
Radio buttons are like checkboxes, except that only one of a set of the buttons can be selected at any time. If a
user selects one of a set of radio buttons, all other buttons in that set are automatically unselected. Exactly one of
the radio buttons in a set must have the CHECKED attribute which sets the default state of the radio button set.
Though this is standard, many sites do not have one checked by default. All radio buttons that comprise a set
have the same NAME.
For example:
A Summary Example
The above example illustrates the form entry mechanisms we just covered. It uses the GET method so you can
see what is being sent to the server. Take a few minutes to look at the source of this web page, and what is being
sent to the server based on your form selections. Be sure you can explain how each of these form entry elements
work, and how various user selections affect what is sent to the server.
What if you need to allow a user to enter multiple lines of text in the browser window? The TEXTAREA element
(note that this is an element itself, not an attribute of the INPUT element) allows a user to have an area with
multiple rows for text entry. Typically, this would be used for a mail message, or a guest-book entry.
The number of rows and columns of the text area are specified by the ROWS and COLS attributes. A vertical
scrollbar is usually present to allow the user to enter more rows of text than the text area window provides. For
example:
A text box of 4 rows long and 40 columns wide will appear on the browser. The string "Any initial text goes here"
will display inside the text box (and will reappear anytime the form containing this text area is reset). When the
form containing this element is submitted, "comments" will be set to the user entry (comments=Userentry). The
value will be URL encoded . This will be discussed later in this module.
The READONLY attribute can be set to disallow the initial text in the window from being over-written. You can use
JavaScript to remove the READONLY attribute to allow the text box to be written to. The attribute WRAP (new
with HTML 5) can be set to hard or soft to determine how the wrapped text will be sent to the server. Some other
attributes that are new with HTML 5 include:
4
AUTOFOCUS – this field should automatically get the focus when the page loads
MAXLENGTH – determines the maximum number of characters allowed for this field
PLACEHOLDER – allows you to show a hint of the type of text that should go in this field
REQUIRED – specifies that this field is required for form submission
A TEXTAREA example
The SELECT element may contain the NAME attribute to name the drop down list. The SIZE attribute determines
how many of the list selections will be visible on the browser; it is up to the browser to determine how the list is
rendered. The typical list style is the pull-down list. If the MULTIPLE attribute is present, then the user is allowed
to make multiple selections from the list.
The OPTION element describes each of the list entries, and can only appear within a SELECT element. The
VALUE attribute of OPTION will be the value sent if this item is selected from the list when the user submits the
form. The text appearing on the browser as the menu selection will be the text contained in the OPTION element
(i.e. the text between the start and end tags.) The LABEL attribute of OPTION, if present, overrides the text.
The SELECTED attribute allows the developer to choose one OPTION element as the default when the page
loads. If the MULTIPLE attribute is present on SELECT, then more than one OPTION element can have the
SELECTED attribute. This causes multiple name=value pairs to be sent.
An example:
</select>
This will render a list on the browser with four of the options visible. The "Rock" option will be selected by default.
A user will be able to select one or all of the menu options (since the MULTIPLE attribute is present). If the user
selects "Jazz" and "Rock", then both "musicstyle=Jazz" and "musicstyle=Rock" will be sent to the server.
Within a list, various choices can be grouped together by use of the OPTGROUP element. The OPTGROUP
element can be contained in a SELECT element to group together list choices. This allows browsers to create a
single depth hierarchy of list choices.
5
An example of OPTGROUP
Buttons (BUTTON)
The BUTTON element is an extended, and more generalized version of the INPUT TYPE="button" element. The
BUTTON element has content; that content will serve as the label for the button, which can be an image, or text
(with HTML).
BUTTON has three standard attributes and eight additional attributes for extra flexibility:
a. submit – a button of type "submit" will cause the form to be submitted to the server when
selected.
b. reset - a button of type "reset" will reset the form to its original state.
c. button - buttons of TYPE "button" (Button buttons) don't do anything specifically – you can just
push it. There is no default behavior. However, the benefit of "button buttons" is that client-side
scripts can be associated with the element's event attributes. When an event occurs (e.g., the
user presses the button, releases it, etc.), the associated script is triggered.
File Select
Setting the TYPE attribute of INPUT to "file" creates a file select control. This is how browsers provide a way to
upload a file from the client to the host's file system. User agents may use the value of the VALUE attribute as the
initial file name. Use this element only with METHOD="post" and ENCTYPE="multipart/form-data".
6
<button>Submit</button>
</div>
</form>
For example:
So, if a particular event occurs, a client-side script can set the "cursorpos" variable to a value. In JavaScript, this
might look like this:
document.Form1.cursorpos.value=12;
In this case, the following will be sent to the server when the associated form is submitted:
cursorpos=12
Of course, we will discuss this much more when we cover JavaScript in a few weeks.
TABINDEX
The TABINDEX attribute allows a page to specify the order in which fields in a form (or hyperlinks) are visited
when the user steps through the form using the keyboard (usually the TAB key). The value of this attribute will be
an integer. The fields are visited in numeric order based on the value of the TABINDEX attribute, from smallest to
largest. These numbers don't need to be successive, in fact, it is best not to make them successive, to allow new
form elements to be inserted easily. Note that other non-form elements, such as anchor elements, can receive the
focus as well; you can also specify a TABINDEX on them.
In the above example, just bring up the page and hit the TAB key, and see what fields are visited in what order.
Sometimes, you might hit a TAB and not see any field being highlighted; this might just be that the focus moved to
the address bar of the browser or some other location that might not be immediately obvious. Make sure you take
a look at the source and see how the TABINDEX attribute is set for each of the elements.
A form control can be READONLY in which case the user cannot change the value. The value can be changed
through scripts, however. A form control can be DISABLED; in that case the user cannot change the value nor will
its value be submitted with the form.
FORMs Layout
By default, FORM input elements will "flow", just like images. You can use style-sheets and positioning to layout
your form.
7
Verifying Form Input
The simplest use of forms is for the user to enter information, and then submit the form. The server then
processes the form input and then sends the resulting web page back to the client. However, for a form with many
entries, it can be annoying to the user to submit the form, and then have the server discover that a simple error
was made by the user during form entry that invalidates the entire form entry. The user then needs to fix the
errors and resubmit.
A much better way to handle this is to check the form input in the client itself, before the form is submitted, quickly
point the user to the mistake and allow the field in the form to be re-entered correctly without involving the server.
This can be done by the use of client-side scripting languages. We will be covering one client-side scripting
language, JavaScript, in a future module, and we will have a lot more to say about this at that point. But, let's
delve into this a bit here, just for fun.
One aspect of this capability is a type of attribute we haven't covered yet – event attributes. Event attributes are
set to an action; and that action is triggered on an event of some sort (events can be changes in form element
values, mouse actions, or even form submission itself). One such event attribute is "onChange". When a value of
a form element (the user entry) is changed, the action associated with the onChange event attribute is triggered.
For example:
Whenever the user enters the text box to enter their "ssn", and changes the content, the JavaScript function
"validateSSN()" will be invoked when the user attempts to leave this field or submits the form. When the
validateSSN() function returns successfully, the form will then be submitted (or the user will simply be able to
leave that field). If the validateSSN() function fails (that is, returns an error), the form will not be submitted, and the
web page can redirect the focus to that field, inform the user of the problem, etc. Be careful how you handle
validations, however. If you continuously inform a visitor that they didn't enter a field correctly, and redirect them
back to that field, it will trap and annoy your visitor. Leave them a way out.
There are essentially three points at which it makes sense to validate form entry:
1. Per keystroke
2. When changing or leaving a field
3. When the form is submitted or reset
Forms in HTML 5
In HTML 5, additional elements and attributes are available. Here are a couple of references. Review these and
use them in your next assignment.