Changes between HTML 3.2 and HTML 4.0 - Forms

There were several problems and shortcomings in the previous HTML 3.2 specification, which this specification addresses.

There was no provision for keyboard shortcuts for particular actions, for access keys for driving menus, etc.

The accesskey attribute provides for specifying direct keyboard access to form fields.

Although form controls could be made insensitive dynamically, they could not be declared as such at initialization time.

The disabled attribute allows form providers to make a form control initially insensitive.

• Disabled elements do not receive focus.
• Disabled elements are skipped in tabbing navigation.
• Values of disabled controls are not submitted with a form.

The following elements support the disabled attribute: INPUT, TEXTAREA, SELECT, OPTION, OBJECT, LABEL, and BUTTON.

How disabled elements are rendered depends on the user agent. For example, some user agents "gray out" disabled menu items, button labels, etc.

In this example, the disabled INPUT element cannot receive user input nor will its value be submitted with the form.

<INPUT	disabled
	name	= "dummy"
	value	= "You can't change this!"
	>

Form controls, such as form fields, could not be made "read only".

With the additional attribute readonly, authors can prohibit changes to a form field.

Labels for radio buttons and checkboxes are not sensitive, i.e., clicking on a label text doesn't effect the button state.

The LABEL element associates a label with a particular form control.

There was no way to markup groups of related form fields in a way that effectively supports browsing with speech-based user agents.

The FIELDSET element groups related fields together and, in association with the LEGEND element, can be used to name the group. Both of these new elements should allow improved rendering and improved interactivity. The FIELDSET element allows form designers to group thematically related controls together. Grouping controls makes it easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents and speech navigation for speech-oriented user agents. The proper use of this element makes documents more accessible to people with disabilities. Speech-synthesis browsers can better describe the form and graphical browsers can make labels sensitive. The LEGEND element allows designers to assign a caption to a FIELDSET. The legend improves accessibility when the FIELDSET is rendered non-visually.

There is no provision for checking values as they are entered into form fields. All checking is done at the server when the form's contents are submitted.

A new set of attributes, including onchange-INPUT, in association with support for scripting languages, allows form providers to verify user-entered data.

Nothing is provided to specify what type of data file is expected when the user is asked to submit files.

The INPUT element has a new attribute accept that allows authors to specify a list of valid media types or type patterns for the input.

Forms can only contain the two buttons submit and reset.

The new BUTTON element can be used to make richer forms. BUTTONs whose type is "submit" are very similar to present 'submit' buttons (INPUT elements whose type is "submit"). They both cause form data to be submitted, but the BUTTON element allows HTML to be used on the button, e.g. for character formatting or to place an image. If a BUTTON is used with an IMG element, use the IMG element's alt attribute to provide a description for users who are unable to see the image.

There was no way to specify what character sets the server issuing a form can handle.

The FORM element includes the attribute accept-charset, modeled on the HTTP "Accept-Charset" header (see [RFC2068]). This attribute (first proposed in [RFC1867]) may be used to specify a list of character sets acceptable to the server.