Chapter 8
The still-growing HTML5 specification first germinated as two other specifications, originally dubbed “Web
Forms 2.0” and “Web Applications 1.0.” Those early specs were an effort to extend and expand upon long-
standing HTML features that were becoming outdated in a Web desperately trying to innovate beyond
them. For example, before HTML5, there was no simple means for a form to validate that a required field
had been filled in, and no simple means for a user to enter something as common as a date of birth.
Another thing the spec authors of times past didn’t anticipate was the rise of web applications—dynamic
and interactive applications accessed through a web browser and built with browser-supported coding
languages (especially HTML, CSS, and JavaScript). Web developers have long had to use heavy-handed
scripts and semantically dubious markup to render common interface widgets like progress bars, boxes
that can open and close, and dropdown lists of suggested field values. HTML5 has at last answered the
call for more interactive elements, paving the way for the next generation of web apps.
As always, you should test your web pages thoroughly in as many different browsers as
you can get your hands on. That’s especially important if you plan to use newer form
controls and interactive elements that may not be widely supported. Don’t make your
forms and applications entirely dependent on the bleeding edge features of a still-in-
progress spec. Practice progressive enhancement and use these newer elements and
attributes wisely.
How Forms Work
Defined in simplest terms, a form is any section of a web page where a user can input information (though
sometimes form elements only display information rather than collect it). Your visitors can enter text into
blank fields, make choices by checking boxes, select options from menus, and then click a button to send
it all away for processing. These interactive devices are called controls, and each control’s data is its
value.
To modify the value of a control, a user must first bring the control into focus so it becomes active and
primed to accept input. A control is usually given focus by clicking it with a mouse or using the Tab key to
move the cursor from one control to the next. Entering a value usually requires typing text or performing
some other deliberate action—clicking a mouse button, pressing the Enter key, and so on. Your visitor can
then shift her browser’s focus to another control, enter another value, and continue on in that fashion,
modifying controls (or skipping over the optional ones) until she reaches the end of the form.
A form isn’t really complete until the user submits it. The information she entered gets transmitted to the
server in a form data set comprising the names of all the form controls and their values. The job of
processing the data set falls to a form handler: a script or program designed to interpret and use the
submitted data. Many form handlers are also designed to validate the entered values, making sure all the
required information has been entered and properly formatted.
Handling submitted form data is another matter entirely; it delves into the complex subjects of scripting,
programming, database design, and application design, and raises issues of encryption, privacy, and
security. Such advanced topics are well beyond the scope of a book about front-end HTML and CSS.
