Understand details of FORM tags

When building web applications, you should have an excellent understanding of how <FORM> tags work.

In particular, there are a number of quirky behaviors that should be noted. When in doubt, you can verify form behavior in various browsers. Since these quirks are often related to browser implementations, and not to the HTML specfication itself, these quirks may change over time.

SELECT Controls

Even if the user has made no selection at all in a <SELECT> control, browsers will automatically submit the first <OPTION> appearing in the body of a <SELECT>. As a workaround, it's often useful to ensure that the first <OPTION> is a blank value, instead of a 'real' one.

File Upload Controls

Curiously, there is apparently no attribute to specify the text of the button used for file upload controls. The text is apparently deduced by the browser from language settings on the client, and not by settings in HTML or HTTP headers.

Reminder: if a form includes a file upload control, then it must have :

Reminder: the Servlet API 2.5 has poor support for file upload requests. As soon as a form includes a file upload control, the format of the underlying request is completely changed. In particular, if no special measures are taken, none of the form's data will be available from request.getParameter(String); this applies to all of the form's data, both file upload controls and regular controls.

Tools such as Apache Commons FileUpload are often used to handle such forms. Also note that support for file upload requests has been added to version 3.0 of the Servlet Specification.

Submit Controls

It's often desirable to distinguish between the appearance of a control, as seen by the end user, and the actual underlying value submitted to the server. (This is particularly true in multilingual applications.) This is indeed possible for all controls, except for the Submit control, whose value attribute is used both for its visual appearance and for its submitted value.

This is a problem in multilingual applications where forms have more than one submit button (further discussion).

Checkbox Controls

When a checkbox control is checked, its name and value are submitted to the server. If the checkbox control is not checked, then it is not submitted at all. That is, the server has two possible tasks: if the request parameter is present, then access its value. If the request parameter is not submitted at all, then the server must assume some default value such as 'null' or 'false'.

Disabled Controls and Read-Only Controls

The readonly and disabled attributes are distinct, and have different behavior. The most important distinction is that readonly items are submitted, while disabled items are not.

When rendering reports or listings that include boolean values, it is tempting to use a disabled checkbox. However, some feel that such disabled checkboxes don't have a very pleasing appearance. One alternative is to use an image instead of a checkbox control, to present the boolean value. (One might even use an image of a checkbox.)

Hitting Enter to Submit

Forms are usually submitted by hitting a Submit button. However, forms can often be submitted just by hitting the 'Enter' key. This behavior is commonly used for web site search boxes.

Be careful that the server can handle both styles of submission - Enter key and Submit button.

TEXTAREA Controls

You often need to exercise care regarding how new lines are handled by your <TEXTAREA> controls. The wrap attribute can often be added to a TEXTAREA to define a desired policy for new line characters. Its values are :
wrap=(hard|soft)

Reminder - POST Versus GET

If an operation has a side-effect (an edit to the database, for example), then method='POST' is highly recommended. If an operation has no side-effect (a list or search operation, for example), then method='GET' is highly recommended.

See Also :
Beware multilingual submit buttons
Wrap file upload requests