WD-forms-970402WD-forms-970402This draft is work under review by the W3C HTML Working Group, for potential incorporation in an upcoming version of the HTML specification, code named Cougar. Please remember this is subject to change at any time, and may be updated, replaced or obsoleted by other documents. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".
A list of current W3C Working Drafts can be found at http://www.w3.org/pub/WWW/TR. This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the HTML working group. Further information about Cougar is available at http://www.w3.org/pub/WWW/MarkUp/Cougar/.
Please send detailed comments to www-html-editor@w3.org. We cannot garantee a personal response, but summaries will be maintained off the Cougar page. Public discussion on HTML features takes place on www-html@w3.org. To subscribe send a message to www-html-request@w3.org with subscribe in the subject.
Although HTML and HTTP were originally designed to provide users with a means to retrieve documents from a server, they also provide for sending user input to the server. Initially only a crude mechanism to enter one or more keywords was supported. This served the need for performing simple queries but it soon became obvious that a more general approach was needed to provide for requesting information from the user. NCSA Mosaic added markups for basic form fields such as radio buttons, checkboxes, single and multiline text fields, single and multiselect menus etc.
Forms have proven to be useful in a wide variety of applications however, as defined in HTML 3.2, they suffer from a number of limitations that this specification addresses.
In addition this document defines some extensions which go beyond the scope of HTML forms. They are meant to improve user agent interactivity in general and to provide better support for speech based user agents in particular.
The forms specified in HTML 3.2 have the following problems:
To solve these problems this specification introduces several new attributes and elements.
In addition user agent interactivity suffers from the following limitations:
To solve these, this document introduces two new attributes:
Some new idioms are only useable in an interactive context, unlike traditional form fields like radio buttons, check boxes and text fields which also make sense on paper. The following features have no hope of backwards compatibility because they either require scripting to be useful, or because old browsers can't provide a reasonable way of dealing with them.
Other proposed extensions will work acceptably with existing browsers, e.g. labeled INPUT fields and labeled groups.
This specification defines a set of elements and attributes powerful enough to fulfill the general need for producing forms. However there is still room for many possible improvements. For instance the following problems could be addressed in the future:
Further extensions are anticipated, but they are not discussed in this document.
The new attributes common to most of the form fields elements are:
accesskey CDATA #IMPLIED -- accessibility key character --
disabled (disabled) #IMPLIED -- to disable element --
onClick %script #IMPLIED -- intrinsic event --
onFocus %script #IMPLIED -- intrinsic event --
onBlur %script #IMPLIED -- intrinsic event --
onSelect %script #IMPLIED -- intrinsic event --
onChange %script #IMPLIED -- intrinsic event --
The following sections described each of these attributes and how they can
be used.
Although authors can choose to supply HTML markups around the appropriate character to control the rendering, the user agent should perform the default rendering accordingly to the appropriate style guide. In general, characters corresponding to an accesskey are underlined. Also, while authors are not required to use a character that is exposed on the label to define an accesskey it is highly recommended.
The way the accesskey is invoked depends on the system but should follow the appropriate style guide. For instance, on Windows one has to press the 'alt' key in addition to the accesskey, and on the Macintosh the 'cmd' key in addition to the accesskey.
Invoking an accesskey performs the same action as clicking on the element. This is following the link for anchors, giving focus for fields, changing the value for radio buttons and checkboxes. In addition for elements other than anchors it is recommended that action, such as scrolling, is taken to get the element into view.
For Example:
<FORM>
<LABEL ACCESSKEY="U">User Name
<INPUT TYPE="TEXT" NAME=USER></LABEL>
</FORM>
This could be rendered as:
When the user types the appropriate key sequence for the accesskey 'U', the input box, user, is given the focus.
DISABLED is an attribute of the INPUT,
TEXTAREA, SELECT, OPTION,
OBJECT, LABEL and BUTTON
elements. When supplied, the related element cannot receive the keyboard
focus and is skipped in the tabbing order. A form control should be
disabled when the form is in a state where this control is irrelevant. For
instance, the submit button could be disabled when the form is presented to
the user and some input is required. The submit button would then be enable
when the user has entered the required data.
When a form control is initially disabled by supplying the
DISABLED attribute, the only way to enable it later on is by
using some associated script to change this state dynamically.
The way disabled form controls are rendered is user agent dependent and should follow the appropriate style guide. In general, disabled form controls are 'grayed out'.
READONLY applies to INPUT elements of type
TEXT or PASSWORD and to the TEXTAREA
element. READONLY is quite like DISABLED as it
prohibits user input however, unlike disabled form controls, read-only form
controls are not considered irrelevant. They can be used to display data
that the user cannot modify in the current state of the form.
Like disabled form controls, read-only form controls can only be made
modifyable by using some associated script to change this state
dynamically.
The way read-only form controls are rendered is also user agent dependent and should follow the appropriate style guide. In general, read only form controls are rendered the same way as modifyable ones; they are not 'grayed out'. But the user just cannot modify their state or content.
The new attributes introduced to improve user agent interactivity are:
title CDATA #IMPLIED -- advisory title string -- tabindex NUMBER #IMPLIED -- position in tabbing order --The following sections described each of these attributes and how they can be used.
The TITLE attribute is used to provide a small piece of extra information that is associated with an interactive element such as an anchor, an image, or a form control. How the title is rendered to the user is up to the user agent but should follow whatever style guide is defined on the system. For instance, on Windows this should be displayed as tooltips and on the Macintosh as help balloons. On other window systems they may be displayed in a status bar. The use of a modal dialog box is not recommended.
For example:
<INPUT TYPE=reset TITLE="Reset form and start over">
The value of TABINDEX is an integer which is used to sort the elements from the lowest to the highest absolute value.
This sort is based on the absolute value to allow authors to use a negative value to indicate that an element is to be left out of the tabbing sequence. This is merely a suggestion though. Indeed when appropriate user agents may ignore this directive. For example speech-based browsers must let users go through every interactive element. Another browser may let the user choose one behavior or the other via some preference setting. For this reason, authors should first give every element a meaningful tabindex, and then mark the ones which are to be skipped by making their tabindex negative.
The example below defines the raw tabbing sequence: field1, field2, and submit, based on the absolute values of their TABINDEX attribute.
<FORM> <INPUT TYPE=TEXT NAME=field1 TABINDEX=1> <INPUT TYPE=TEXT NAME=field2 TABINDEX=-2> <INPUT TYPE=SUBMIT NAME=submit TABINDEX=3> </FORM>
However, the negative tabindex of field2 indicates that this text field is to be skipped in the tabbing sequence.
There is no requirement that the values of TABINDEX be consecutive or that they begin with any particular value. When there are more than one element with the same tabindex value the order of appearance in the document source is used to sort them out.
Thus, in the following example the tabbing sequence is: field1, field2, field4, submit.
<FORM> <INPUT TYPE=TEXT NAME=field1 TABINDEX=1> <INPUT TYPE=TEXT NAME=field2 TABINDEX=2> <INPUT TYPE=TEXT NAME=field4 TABINDEX=2> <INPUT TYPE=SUBMIT NAME=submit TABINDEX=4> </FORM>
Finally, to ensure reasonable down-level compatibility, form controls and anchors without an explicit tabindex are given an implicit value based on their order of appearance in the document source. And these elements are always part of the tabbing sequence.
Based on this, the example below defines the tabbing sequence: help, field1, field2, field4, field3.
<a href="help" >Help</a> <FORM> <INPUT TYPE=TEXT NAME=field1 TABINDEX=1> <INPUT TYPE=TEXT NAME=field2 TABINDEX=2> <INPUT TYPE=TEXT NAME=field4> <INPUT TYPE=SUBMIT NAME=submit TABINDEX=4> </FORM>
Each successive tab key takes the focus to the interactive element with the next greater value of tabindex. After visiting the element with the greatest value of tabindex, the next tab key returns to the initial element. Pressing Shift-tab should be interpreted as a reverse tab.
A variety of HTML elements may in principle be associated with keyboard events, for instance, form fields, hypertext links, embedded objects and client-side image maps. Embedded objects capable of receiving the keyboard focus should form part of the tabbing sequence. Such objects may in turn consist of subsidiary objects which themselves can get the focus. In this situation, these objects form a tabbing sequence that is inserted into the tabbing sequence of the parent HTML document. Client-side image maps may define a tabbing sequence, giving users the ability to tab through the various hotzones. The Enter key can be used to activate the object with the focus, whether this is a hypertext link or a radio button in a form field.
Incremental display of documents as data is received from the network creates special problems. The idea that the focus is given to the lowest valued tabindex within the whole document seems reasonable enough at first glance. But it would mean having to wait until all of the document's text is received, as until then, the lowest valued tabindex is liable to change. If the user hits the tab key before then, it is reasonable to move the focus to the lowest currently available tabindex.
This section describes the new elements which are introduced to make richer forms possible.
<!ELEMENT LABEL - - (%text)* -(LABEL) -- field label text --> <!ATTLIST LABEL %attrs; -- id, class, style, lang, dir, title -- for IDREF #IMPLIED -- matches field ID value -- disabled (disabled) #IMPLIED -- control is unavailable in this context -- accesskey CDATA #IMPLIED -- accessibility key character -- onClick %script #IMPLIED -- intrinsic event -- onFocus %script #IMPLIED -- intrinsic event -- onBlur %script #IMPLIED -- intrinsic event -- >
The LABEL element requires start and end tags. Labels cannot be nested. This element serves two purposes: it provides a way to structurally associate a description with a form control and it provides a user interface active region for selecting the form control.
While speech-based browsers can take advantage of the description to easily describe the associated element, on systems that expose a pointing device, clicking on the label gives the form control the focus by generating a click on the element itself. For instance, this causes the value of an option button to change.
Labels can be associated either implicitly or explicitly. Labels are implicitly associated when the LABEL tag is wrapped around the element. Such labels can only contain a single form control. And the actual label may appear either before or after the contained element.
Example:
<!-- Implicit Labels --> <LABEL> First Name <INPUT TYPE="TEXT" NAME=FIRSTNAME> </LABEL> <LABEL> <INPUT TYPE="TEXT" NAME=LASTNAME> Last Name </LABEL>
Implicit labels have the disadvantage to require the label and the associated element to be constructed together. In some cases it is necessary to define them separately though. An example is when one wants to have the label in the first column of a table, and the related form control in the second column. Explicit labels provide for doing this by using the FOR attribute to make the association. The form control is referenced by its ID. Associations are limited to form controls within the same page. More than one label may be associated with a single form control by creating multiple references.
Example:
<!--Explicit Label-->
<TABLE>
<TR>
<TD><LABEL FOR=FNAME>First Name</LABEL>
<TD><INPUT TYPE=TEXT NAME=FIRSTNAME ID=FNAME>
<TR>
<TD><LABEL FOR=LNAME>Last Name</LABEL>
<TD><INPUT TYPE=TEXT NAME=LASTNAME ID=LNAME>
</TABLE>
<!ELEMENT BUTTON - -
(%text | %block)* -(A | %formctrl | FORM | ISINDEX | FIELDSET)>
<!ATTLIST BUTTON
%attrs; -- id, class, style, lang, dir, title --
disabled (disabled) #IMPLIED -- control is unavailable in this context --
tabindex NUMBER #IMPLIED -- position in tabbing order --
onClick %script #IMPLIED -- intrinsic event --
onFocus %script #IMPLIED -- intrinsic event --
onBlur %script #IMPLIED -- intrinsic event --
>
The BUTTON element allows richer forms with buttons different from the two submit and reset basic buttons available via the INPUT element. With this element whole HTML fragments can be encapsulated within buttons. The BUTTON element is a container which can basically contain any non interactive element such as a BUTTON, a FORM, etc... Start and end tags are required.
Example: In this example the BUTTON element is used to define a button which contains an icon plus some text.
<BUTTON> <IMG ALIGN=middle SRC="helpicon.gif"> Help <P> <em;>Click here to get information about how to fill in this form </em;> </BUTTON>
The BUTTON element by itself is not sufficient though. It is intended to be used in association with some script define through its onClick attribute as well as other attributes related to the Intrinsic Events, see HTML Scripts for further details.
The width and height of a button can be specified through the style sheets. However the actual width and height are determined by following these rules:
User agents should try their best to avoid clipping the button contents. This can occur when the button size is set too small, or when the button extends past the right margin so that it is clipped by the edge of the window.
In the former case, the user agent should increase the width and/or height as needed to avoid clipping. In the latter case, the button width should be reduced to avoid the button being clipped by the window edge. If there is still insufficient space, then the line can be wrapped to place the button on a new line.
<!-- #PCDATA is to solve the mixed content problem, by specification only whitespace is allowed there! --> <!ELEMENT FIELDSET - - (#PCDATA,CAPTION,%body.content)> <!ATTLIST FIELDSET %attrs; -- id, class, style, lang, dir, title --
The FIELDSET element is similar to the DIV element but is for the specific purpose of grouping related fields. It is a container and it is nestable. It requires start and end tags and can contain a single CAPTION that must immediately follow the FIELDSET tag. The caption is used to identify the contained set of fields. This is especially useful to speech-based browsers which can then provide users with a way to move from group to group.
The rendering for a field set is left up to the browser. However it is recommended to place a box around the group and transpose the caption over the upper-left or lower-left portion of the box depending upon the align attribute value on the CAPTION element.
<FIELDSET>
<CAPTION ACCESSKEY=G TABINDEX=1>Gender</CAPTION>
<LABEL ACCESSKEY=M><INPUT TYPE=RADIO
NAME=Gender VALUE=Male>Male</LABEL><BR>
<LABEL ACCESSKEY=F><INPUT TYPE=RADIO
NAME=Gender VALUE=Female>Female</LABEL>
</FIELDSET>
When a caption in a FIELDSET has a TABINDEX or an ACCESSKEY, when the FIELDSET is tabbed or referenced through the ACCESSKEY, the control within the FIELDSET with the lowest tabbing order receives the focus.
The DTD fragment below exhibits the new elements and attributes discussed in this document.
<!ELEMENT FORM - - %body.content -(FORM)>
<!ATTLIST FORM
action %URL #REQUIRED -- server-side form handler --
method (GET|POST) GET -- see HTTP specification --
enctype %Content-Type; "application/x-www-form-urlencoded"
onSubmit %script #IMPLIED -- intrinsic event --
target CDATA #IMPLIED -- where to render result --
accept-charset CDATA #IMPLIED -- list of supported charsets --
>
<!ELEMENT LABEL - - (%text)* -(LABEL) -- field label text -->
<!ATTLIST LABEL
%attrs; -- id, class, style, lang, dir, title --
for IDREF #IMPLIED -- matches field ID value --
disabled (disabled) #IMPLIED -- control is unavailable in this context --
accesskey CDATA #IMPLIED -- accessibility key character --
onClick %script #IMPLIED -- intrinsic event --
onFocus %script #IMPLIED -- intrinsic event --
onBlur %script #IMPLIED -- intrinsic event --
>
<!ENTITY % InputType
"(TEXT | PASSWORD | CHECKBOX |
RADIO | SUBMIT | RESET |
FILE | HIDDEN | IMAGE | BUTTON)"
>
<!-- HSPACE and VSPACE missing due to lack of widespread support -->
<!ELEMENT INPUT - O EMPTY>
<!ATTLIST INPUT
%attrs; -- id, class, style, lang, dir, title --
type %InputType TEXT -- what kind of widget is needed --
name CDATA #IMPLIED -- required for all but submit & reset --
value CDATA #IMPLIED -- required for radio and checkboxes --
checked (checked) #IMPLIED -- for radio buttons and check boxes --
disabled (disabled) #IMPLIED -- control is unavailable in this context --
readonly (readonly) #IMPLIED -- for text and passwd --
size CDATA #IMPLIED -- specific to each type of field --
maxlength NUMBER #IMPLIED -- max chars for text fields --
src %URL #IMPLIED -- for fields with images --
align %IAlign #IMPLIED -- vertical or horizontal alignment --
usemap %URL #IMPLIED -- use client-side image map --
tabindex NUMBER #IMPLIED -- position in tabbing order --
onClick %script #IMPLIED -- intrinsic event --
onFocus %script #IMPLIED -- intrinsic event --
onBlur %script #IMPLIED -- intrinsic event --
onSelect %script #IMPLIED -- intrinsic event --
onChange %script #IMPLIED -- intrinsic event --
accept CDATA #IMPLIED -- list of MIME types for file upload --
>
<!ELEMENT SELECT - - (OPTION+)>
<!ATTLIST SELECT
%attrs; -- id, class, style, lang, dir, title --
name CDATA #REQUIRED -- field name --
size NUMBER #IMPLIED -- rows visible --
multiple (multiple) #IMPLIED -- default is single selection --
disabled (disabled) #IMPLIED -- control is unavailable in this context --
tabindex NUMBER #IMPLIED -- position in tabbing order --
onFocus %script #IMPLIED -- intrinsic event --
onBlur %script #IMPLIED -- intrinsic event --
onChange %script #IMPLIED -- intrinsic event --
>
<!ELEMENT OPTION - O (#PCDATA)*>
<!ATTLIST OPTION
%attrs; -- id, class, style, lang, dir, title --
selected (selected) #IMPLIED
disabled (disabled) #IMPLIED -- control is unavailable in this context --
value CDATA #IMPLIED -- defaults to element content --
>
<!ELEMENT TEXTAREA - - (#PCDATA)*>
<!ATTLIST TEXTAREA
%attrs; -- id, class, style, lang, dir, title --
name CDATA #REQUIRED
rows NUMBER #REQUIRED
cols NUMBER #REQUIRED
disabled (disabled) #IMPLIED -- control is unavailable in this context --
readonly (readonly) #IMPLIED
tabindex NUMBER #IMPLIED -- position in tabbing order --
onFocus %script #IMPLIED -- intrinsic event --
onBlur %script #IMPLIED -- intrinsic event --
onSelect %script #IMPLIED -- intrinsic event --
onChange %script #IMPLIED -- intrinsic event --
>
<!--
#PCDATA is to solve the mixed content problem,
by specification only whitespace is allowed there!
-->
<!ELEMENT FIELDSET - - (#PCDATA,CAPTION,%body.content)>
<!ATTLIST FIELDSET
%attrs; -- id, class, style, lang, dir, title --
<!ELEMENT CAPTION - - (%text;)+>