HTML Forms

Forms are block elements designed to act as containers for HTML controls such as text boxes, radio buttons etc that can be the target of user interaction via the keyboard or the mouse. Contrary to commonly held belief, such controls do not have to be placed inside form containers. Indeed, there is little to be gained by doing this if all one wants to do is to provide interactive controls whose contents are examined and manipulated by JavaScript run on the web browser. However, forms provide a convenient shorthand mechanism for for collating user supplied information and shipping it to another Internet location for further analysis and action. This is because forms define attributes which, when correctly specified, automate the data collation and shipping processes. These attributes - and others which forms share in common with other HTML elements - are listed below

• The class attribute is discussed here. One can locally alter some aspects of the assigned style by defining an inline style using the code style="color:...". Needless to say, only those style attributes that require altering/adding need to be specified.
• The id attribute is discussed here.
• The events available across all three browsers - Firefox, Opera and IE - are discussed here.
• The style attribute is used to assign inline CSS styling information to the element. The specification takes the form style="color:...". Inline styling should be used sparingly to temporarily override CSS attributes inherited from a class specification.
• action:This is the URL of the Internet resource to be used to process form data. Typically, one would point to a script - written in PHP, ASP or one of the other diverse server-side scripting languages - which would read in the user data, process it, modify it, update database entries etc.
• enctype:This determines how form control data are encoded when they are shipped of to the URL described by the action attribute. There are two possibilities:
  • application/x-www-form-urlencoded:This is the default value. With this setting form data are compacted together into a string using the following rules
    • Named form fields are compacted together in the order in which they occur on the form.
    • Spaces are replaced by the + character.
    • Non alphanumeric characters are replaced by their hexadecimal representation, %HH.
    Just how this compacted string is sent out depends on the verb specified in the method attribute, discussed below.
  • multipart/form-data:This specification is completely ignored if the verb specified in the method attribute is GET. If the verb POST is used the form data are appended to the HTTP request header.
• method:The method attribute specifies one of two verbs:
  • GET:Generally speaking this verb should be specified if the form action merely results in fresh information being obtained from the server without changing the state of the server - e.g. by updating or making a database entry. Form data - after being compacted into a string, as discussed above - are appended to the URL specified in the action attribute followed by a question mark, ?, character. In other words, url?form-data. There are practical reasons why one might choose to use POST even though the form action does not cause any changes in server state:
    • The length of the composite URL + encoded form data string should not be too long. Precisely what is meant by "too long" depends on the browser-server combo that deals with the request. In our experience a length of up to 1024 characters is generally safe. In practice, we find it prudent to stop well short of this limit.
    • If the form contains one or more file upload fields GET is an unsuitable method.
  • POST:This method is always safe to use. The HTTP request header is followed by two CR/LF (carriage return and line feed) characters and the appended form data. The manner in which form data are appended depends on the enctype attribute.

The effects of different enctype and method combinations are discussed here.