Please consult my document How to write HTML forms for general information on forms, such as tutorials, references, and basic notes on processing form data by server-side scripts. This section will just make a few additional notes.
The form concept in HTML is simple, if not simplistic. You might have difficulties in seeing this when you look at the description of forms in HTML specifications, especially in the most extensive one (HTML 4). The complexity of the specifications in this area is however mostly related to details.
A form in HTML is essentially just a data structure describing the fields of possible user input at a rough level. You can specify the generic type of an input field (one line of text, several lines of text, choice between given alternatives, form submission request, request to clear the form).
It is probably useful to state explicitly some examples of what you cannot do with forms in HTML:
Despite the limitations, forms have turned out to be very useful. In a sense, they are largely useful thanks to being simple and limited: almost all browsers have supported forms for a long time, so they are widely accessible in various browsing situations.
The work in progress as regards to enhancing the HTML form concept illustrates the above-mentioned limitations in the current form concept. See XHTML Extended Forms Requirements.
Generally speaking, client-side scripting in relation to HTML means that some relatively simple code, which is embedded into an HTML document or referred to in it, is executed by the user's Web client (browser, such as Netscape, Opera, or Internet Explorer). The code might, for example, dynamically modify the HTML document (more exactly, a copy of it as processed and displayed by the browser), or it might open a new window on the user's screen. The code is written in some specific language designed for the purpose.
Section Scripts in the HTML 4.0 specification describes the different interfaces between HTML and scripting languages. In particular, it specifies some "intrinsic events" which are part of the interface.
mentioned above before posting. You can also search from
the group using
To take a simple example, you could use the following for focusing on a form field:
However, there is the view that automatic focusing is undesirable and that focusing should be left to the user. And especially on large pages it might really happen that the part of a page, including a form, has loaded, the user starts filling out the form, and then the page finishes loading and focus is moved away from the field where the user was!
META element is used to
specify the scripting language used.
In principle, the
attribute value could be written in any scripting language.
However this is mainly theoretical; browsers that support
The HTML 4.0 Specification did not allow a
attribute for a
This means that such attributes give validation errors when
validating against any HTML 4.0 DTD. However, the
HTML 4.01 Specification
which contains several
(usually small ones) as compared with HTML 4.0, allows
NAME attribute for those
FORM and for
IMG elements. Thus, you can
now use the following
document type declaration if you use
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html40/loose.dtd">(or perhaps
strict, if you don't use deprecated features; or
framesetfor frameset documents).
Although this was expected to resolve the issue, the
XHTML 1.0 specification
re-introduced the problem, in the following sense:
In XHTML 1.0, the Transitional version allows the
the Strict version does not. Apparently, you can switch to the
Transitional DTD if this is a problem.
Some historical notes on previous solutions and background:
to a specific form element using
NAME attribute in
FORM tag, as in
focusing example above.
However, the logical way to uniquely identify an element
would be via an
ID attribute - which is
allowed by HTML 4.0 but unfortunately supported
by browsers less widely than the
the thread NAME is an IMG tag
December 1998 in the
WDG Validator documentation contains
instructions for using a customized DTD.
In this case it would suffice to use
an HTML 4.0 DTD with the simple extension which
our example modified to refer to that DTD -
But currently this is not needed
any more, since you can just use
the HTML 4.01 DTDs.
When referring to
dynamically replace an image by another
one normally uses
by using a
The causes validation problems as explained above.
One solution used was
when referring to the first image on a page). This could be feasible
if there are just a few images on the page. But using numbers
for such purposes is error-prone (do you remember to change
the numbers if you add images? even when in hurry to meet a deadline?),
and it is discouraged in
and since the approval of HTML 4.01, there's no reason any more
to use that method.
So let's assume that you wish to make the word "foo" a link
so that when the user clicks on it, the page
will open in a new browser window which is 150 pixels wide and
150 pixels high. (Just simple properties, for illustration; see
Window Spawning and
WebReference for some
Let's start from the wrong way of doing it:
The problem with this is that when a browser does not
The user will see "foo" as a link but clicking on it does nothing.
so they won't find
somedoc.html through that construct.)
It won't help to do something like the following
in place of an
<a href="#" onClick="popup()">foo</a>
This approach is for some reason popular, but of course
href="#" makes no sense.
# is technically a URL reference, it means
is disabled, the "link" thus degrades to something that causes the
document to be positioned at the start, potentially confusing the
There is a simple example page using this method. It also contains some further caveats and notes.
clicking on the link will cause the value of the
attribute to be executed first. This will create a new window
with the desired properties but not load anything into it yet.
the browser does normal link processing,
somedoc.html and then
targetattribute with the name of the window) or
As an alternative method, you could write:
<a href="somedoc.html" target="somename" onclick= "return !window.open('somedoc.html','somename', 'width=150,height=150,resizable=1')">foo</a>
If the window is successfully opened, the
function returns the value
true, which is changed to
false by the negation operator
Thus, on successful opening, the entire expression returns
false, and thius tells the browser not to perform the
to replace rather than precede it).
This feature is not supported by browsers such as IE 3
the return value
they would try to follow the link normally
just unnecessary extra operation; but with the
omitted, it would result in opening
somedoc.html both in a new
window and in the original window!
considerations apply to directing output
from form submission to a new window with some specific
properties. You would use an
FORM tag, together with a
attribute in the same tag. Example:
<FORM ACTION="http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi" target="FOLDOC" onsubmit= "window.open('','FOLDOC','resizable=1,scrollbars=1,width=400,height=300')" > <INPUT NAME="query"> <INPUT TYPE="submit" NAME="action" VALUE="Search"> </FORM>
Try it (it will search for a word definition in the Free On-Line Dictionary of Computing)
A rather common special case of opening a new window in
a specific size is a link to an image. It is natural
to try to make the window as small as possible. One problem with
this is that browsers may use different amounts of padding around an
image, if you only link to an image as such. You can't affect that
padding, but you might affect the padding around an image if it is part
of an HTML page (or the sole content of an HTML page).
Moreover, you might wish to have some explanatory text (image caption)
in the window, too.
Hence it might be better
to make the link point to an HTML document containing the image (and little
or nothing else). You might find it comfortable to construct the HTML
href attribute pointing to the image, as a fallback
The simplest approach is to write an input field normally,
That is, you would not use a
input element in HTML markup
but assign the date (as a string)
to the element's
separate files (referred to via
script src="..." elements in HTML)
script elements in the document head,
instead of "inlining" it as above. The code above is just a compact
Assume that your form has some fields for numeric input by the user, such as quantity of items he is about to purchase. You might wish to include, as extra convenience to some users, a client-side script which dynamically calculates and displays a running total.
To illustrate the basic idea, we consider an extremely
simplified version where the data to be displayed
is just the sum of two fields.
Let us assume that user input is via selecting an option
SELECT menu, which means that he has
a predefined set of alternatives.
If data input is via a text input field, there will be more
complications. You would probably want to
the data for being numeric, and it would be more difficult
to make the sum information change in a manner which cannot
mislead the user.
Note that the
onchange attribute is
handled by browsers so that
an event is not interpreted to occur just because
the user uses the mouse to move the cursor away from the input field,
but it occurs when you focus on another field
(e.g. by clicking on another field in order to start typing there,
or by "tabbing" to the next field).
The code for it could be the following:
It looks like the following on your browser: