HTML and CSS Reference
In-Depth Information
Form element attributes
The following sections describe each of the form attributes in detail.
The action attribute
The action attribute tells the user agent (the web browser) what it's supposed to do
with the contents of the form when the form is submitted (with a submit button, which is
a form control element we'll discuss later). As in the earlier example, a server-side script
can be specified to handle the submitted form data. If it is omitted, the form will redirect
to the same URL it is submitted from.
The method attribute
The method attribute is where the form is set to use GET (the default) or POST. The
general rule of thumb is that if the form submission is actively modifying data (such as
updating a server-side database in some way) or includes sensitive information (such as
a password), your form should use POST . On the other hand, if the form submission is
passive, such as a database query for a search engine, then use GET . Why? Having the
data visible in the page's URL (using GET) will allow the page to be bookmarked, which
is useful for a search query, while not having it in the URL (using POST) offers better
security for sensitive data. Also, GET is better suited to short amounts of data since it
has size limitations because the URL can only be so long (the actual length varies by
web browser).
The accept-charset attribute
The accept-charset attribute allows you to specify which character encodings the
server can handle in the submitted form data. If not specified (the usual scenario), the
character set of the page is used (as should be set in the head section using the meta
element and/or sent in the server's HTTP response header). This attribute can be a space-
separated list of values if several character sets are acceptable; however, to avoid is-
sues of characters displaying incorrectly, always use UTF-8 when dealing with encod-
ing. UTF-8 supports all the world's major languages.
The enctype attribute
The enctype attribute is used to specify how to encode the form data when it is sent.
It takes three possible values: application/x-www-form-urlencoded , mul-
tipart/form-data , and text/plain . In most cases, it can be omitted, because it
will default to the first value mentioned, which will encode the data in a URL-safe man-
ner. This is typically needed to differentiate ambiguous form data from other informa-
tion. For instance, if some form data had a forward slash (a solidus) in it, this would
Search WWH ::

Custom Search