More about WEB PAGE
Anatomy of the <head>
- Understanding the need to group content
- Using the div Element
- Grouping content into lists
- Dealing with figures
Creating advanced tables
- Adding table headers cells
- Denoting the headings and the table body
- Creating irregular tables
- Applying borders to the table element
- The action attribute
- The method attribute
- Configuring the Data Encoding
- Controlling form completion
- Setting the name of the form
- Adding labels to a form
- Automatically focusing on an input element
- Disabling individual input elements
- Grouping form elements together
- Using the button element
Customizing the input element
- Using the input element for text input
- Setting values and using placeholders
- Using a data list
- Creating read-only and disabled text boxes
- Restrict data entry
Using input validation
The enctype attribute specifies how the browser encodes and presents the data to the server. There are three allowed values for this attribute, which are described in the table below.
To understand how the different encodings work, you need to have two input elements in your form as shown below.
<html> <head> <title>Example</title> <meta name="author" content="Adam Freeman"/> <meta name="description" content="A simple example"/> <link rel="shortcut icon" href="favicon.ico" type="image/x-icon" /> </head> <body> <form method="post" action="http://titan:8080/form"> <input name="fave"/> <input name="name"/> <button>Submit Vote</button> </form> </body> </html>
You need two input elements so that you can collect two items of data from the user. As you may have guessed, you are building up a form that will allow users to vote for their favorite fruits. The second input element will be used to gather their names. As you can see above, we set the name value of this element to be name. To demonstrate the effect of the different form encodings, we have to add the enctype attribute to the form and set it to each of the supported encoding types.
In each instance, I enter the same data into the text boxes. In the first text box I enter Apples, and in the second I enter Adam Freeman (with the space between my first and second names). Now let’s see how this data is encoded by the different techniques.
The application/x-www-form-urlencoded Encoding
This is the default encoding, and it is suitable for every kind of form except those that upload files to the server. The name and value of each data item is encoded using the same scheme that is used to encode URLs (hence, the urlencoded part of the name). This is how the encoding is applied to the data in the example form:
Special characters are replaced with their HTML entity counterpart. The name of the data item and the value are separated by the equals sign (=) and data/value tuples are separated by the ampersand character (&).
The multipart/form-data Encoding
The multipart/form-data encoding takes a different approach. It is more verbose and more complex to process, which is why it tends to be used only for forms that need to upload files to the server— something that can’t be done using the default encoding. Here is how the data from the example form is encoded:
------WebKitFormBoundary2qgCsuH4ohZ5eObF Content-Disposition: form-data; name="fave" Apples ------WebKitFormBoundary2qgCsuH4ohZ5eObF Content-Disposition: form-data; name="name" Adam Freeman ------WebKitFormBoundary2qgCsuH4ohZ5eObF-- fave=Apple name=Adam Freeman
The text/plain Encoding
This encoding should be used with caution. There is no formal specification as to how data should be encoded when using this scheme, and the mainstream browsers encode data in different ways. For example, Google Chrome encodes data in the same way as for the application/x-www-form-urlencoded scheme, whereas Firefox encodes the data as follows:
fave=Apple name=Adam Freeman
Each data item is placed on a line, and special characters are not encoded. We recommend avoiding this encoding. The variations between browsers make it unpredictable.