This document is an intermediate draft produced by the W3C HTML Working Group Board as part of the HTML Activity; it is stable enough to be released for public comment (to www-html@w3.org) but may change before approval as (part of) a recommendation. Hence it should not be implemented as part of a production system, but may be implemented on an experimental basis.
This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. 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 technical reports can be found at http://www.w3.org/pub/WWW/TR. Since working drafts are subject to frequent change, you are advised to reference the latter URL, rather than the URL for this working draft.
The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This document reviews the design requirements for forms in hypertext documents and presents some possible directions for extending HTML 2.0 to meet these requirements. A phased implementation plan is proposed.
The initial version of HTML provided a crude mechanism for entering one or more keywords to be sent to an HTTP server to perform a query. It soon became obvious that a more general approach was needed. NCSA Mosaic added markup for basic form fields such as radio buttons, checkboxes, single and multiline text fields, single and multiselect menus etc. When the user presses the submit button the contents of the form are converted into a list of attribute/value pairs and sent to the server for processing.
The approach allowed for initializing form fields but suffers from a number of problems:
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.
It is proposed that changes to HTML form capabilities are phased in during two or more rounds of extensions:
You will also find a Fragment DTD at the end of this document.
Phase two will address more complex control types, menu enhancements, multiple page layouts, and server driven updates. Phase Two is not discussed within the context of this document.
Value: Single Character
Initial Value: None
Applies To: Label, Anchor, and Caption
Justification: Accessibility for systems without a mouse or other pointing device. Optimization for more sophisticated users.
The AccessKey is an attribute on the Label and Anchor Tag. The AccessKey takes a single character in the current charset that provides a keyboard shortcut for clicking on the label or anchor. To the user, the accesskey is case insensitive. For example, when the accesskey is set to 'u' or 'U', it should not matter whether the user referenced an upper or lower-case 'u', both should work. There is no suggested or required rendering for the AccessKey. The author can choose to supply HTML around the appropriate letter with their own specified rendering. The accessKey is invoked on Windows pressing the 'alt' key in addition to the accessKey and on the Macintosh by pressing the 'cmd' key in addition to the AccessKey. Invoking an accessKey performs the same action as clicking on the element (follows the link for anchors, or scrolls the element specified by the caption or label into view) For example:
<STYLE>
span.access {text-decoration:underline;font-size:+1}
</STYLE>
<LABEL for=radioMale accessKey=M><SPAN class=access>M</SPAN>ale</LABEL>
<INPUT type=id=radioMale value="Male">
The keyboard focus determines which object in a document gets keyboard events. Until now, most browsers require you to use the mouse (or other pointer device) to give the focus to the form field you wish to interact with or they assume an implicit order based on the document's source. By default, all elements should play in the tabbing order unless the element is explicitly marked not as a tabstop. This is necessary to ensure reasonable down-level compatibility with documents that rely on the browser's implementation to provide a tabbing order.
The proposed tabindex attribute:
Incremental display of documents as data is received from the Net creates special problems. The idea that the focus is given to the lowest valued tabindex seems reasonable enough at first glance, but 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.
Browsers should prevent forms from being submitted until all of the form's elements have been received. If forms are associated with client-side scripts, there is further potential for problems. For instance, a script handler for a given field may refer to a field which doesn't yet exist!
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.
What is the default tabbing behavior for form fields without a tabindex attribute? One approach is to define tab order according to the order in which the fields appear in the HTML markup. What happens if the some, but not all fields have tabindex attributes? How does this interact with incremental display? For instance when the first few fields don't have tabindex attributes, and the next few do. In this case, the browser would apply the default tabbing behavior until fields were seen with the tabindex attribute.
It might seem reasonable to disable tabbing through fields without a tabindex attribute, but this is probably unacceptable to terminal-based browsers without pointer devices. The safest course is for tabindices to be implicitly defined unless explicitly overridden by the tabindex attribute. When the order is implicit, the order should be defined by the source order. To always skip the element, tabindex of '-1' attribute is explicitly supplied.
Each successive tab key takes the cursor to the input element with the next greater value of tabindex. After visiting the element with the greatest value of tabindex, the next tabkey returns to the initial element. Pressing Shift-tab should be interpreted as a reverse tab.
There is no requirement that the values of tabindex be consecutive or that they begin with any particular value. If multiple elements in the same form have the same tabindex value, the browser may choose any one of them or all of them in turn -- this is a markup error.
The intent is to treat the new tabindex attribute in the same way that OS/2 Presentation Manager and Microsoft Windows treat the tabindex attribute in their controls..
For example:
<INPUT TYPE=TEXT NAME=FOO TABINDEX=1> <INPUT TYPE=BUTTON NAME=SKIP TABINDEX=-1> <!--Can't tab here--> <INPUT TYPE=TEXT NAME=ZAM> <!--Can tab here, Taborder implicitly assumed to follow FOO--> <INPUT TYPE=TEXT NAME=BAR TABINDEX=2>
Value: String
Initial Value: None
Applies To: All Elements
Justification: To provide similar functionality to window's tooltips and macintosh's balloon help.
The title attribute is used to provide a small piece of extra information that is associated with an anchor, image, or intrinsic control. How the tip is rendered to the user is up to the UA. On Windows, tips are generally displayed when the mouse hovers over the element as small pop-up windows. Once the mouse is subsequently moved or clicked, the window goes away. On the Macintosh, the tip may be displayed as baloon help. Other operating systems may choose to display tip text in a status bar. It is recommended that tips are not displayed in a model dialog box.
For example:
<IMG SRC=main.gif TITLE="Click where you want to go">
Applies To: input, textarea, select, object, fieldset, button
Justification: Currently there is no way to disable a control from receiving the focus
When supplied, the control will be disabled. Disabled controls cannot receive the focus and are skipped in the tabbing order. On windows (need other operating systems), the control is usually rendered in 'grayed' out state. When this attribute is supplied, the element is initally disabled.
<label for=id AccessKey=character></label>
Justification: The current HTML model lacks a way to associate the label with a particular control.
Labels for radio buttons and checkboxes are currently missing from HTML. Authors can place text next to the fields, but the connection is missing from the markup. This means clicking on the label text doesn't work. This is a minor nuisance for most of us, but a critical failing for the visually impaired. Speech-based browsers are forced into the unsatisfactory position of having to use the NAME and VALUE attributes to describe each field.
The new label element serves two purposes: To structurally associate a description with an input control and to provide a UI active region for selecting a control. On systems that expose a pointing device, clicking on the label gives the control the focus by generating a click on the control. For buttons that keep state (i.e,. option buttons and checkboxes) this causes the value to change.
Labels can be associated either implicitly or explicitly. Labels are implicitly associated with controls by wrapping the Label tag around a control. Implicit labels can only contain a single object or control-like element. For implicit labels, the label may appear either before or after the control. Labels cannot be nested, and there is no limit to how many labels may be associated with a single element.
A disadvantage to implicit labels are they assume they can be constructed within the same context of the control. To allow labels to be independently positioned, explicit association can also be made. An example where this is necessary is where you want to have the labels in the first column of a table, and the control in a second column. Explicit association is done with the FOR attribute. The FOR references the ID of a control on the page. More than one label may be associated with a single control by creating multiple for references.
Examples:
<!--Implicit Label--> <LABEL ACCESSKEY=U>User Name<INPUT TYPE="TEXT" NAME=USER ID=USER></LABEL>
<!--Explicit Label-->
<TABLE><TR><TD>
<LABEL FOR=USER ACCESSKEY=U>User Name</LABEL>
</TD><TD>
<INPUT TYPE=TEXT NAME=USERNAME ID=USER></TD>
</TR>
</TABLE>
Justification: Accessibility. For example, in a speech-synthesized browser, this allows the user to move from group to group. This is similar to the DIV but is for the specific purpose of grouping related fields on a page.
The FieldSet Tag is a container and nestable. Its content model is body-content. A FieldSet can contain a single caption that must immediately follow the FieldSet tag. The caption is used to identify the contained set of fields.
The rendering for a field set is left up to the browser. The recommended rendering is 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.
<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 uses HTML 3.2 for the basis: "-//W3C//DTD HTML 3.2//EN"
<!-- Added label to %text --> <!ENTITY % text "#PCDATA | label | %font | %phrase | %special | %form">
<!-- defined new entities for control and label --> <!ENTITY % control "%form | img | object | applet"> <!ENTITY % labelcontent "#PCDATA | %font | %phrase | FONT | SCRIPT">
<!-- defined element LABEL --> <!ELEMENT LABEL - - ((%labelcontent)*, (%control)?, (%labelcontent)*)>
<!ATTLIST LABEL for IDREF #IMPLIED -- for is required when using explicit labels -- accesskey CDATA #IMPLIED --accessibility key character-- title CDATA #IMPLIED --advisory title string-- >
<!-- Added fieldset to %block--> <!ENTITY % block "P | %list | %preformatted | DL | DIV | CENTER | BLOCKQUOTE | FORM | ISINDEX | HR | TABLE | FIELDSET">
<!-- defined element FIELDSET --> <!ELEMENT FIELDSET - - (caption?, %body.content)>
<!ATTLIST FIELDSET title CDATA #IMPLIED --advisory title string-- >
<!-- Added title to the following elements--> <!-- Added download to the following tags if they have a src attribute--> <!-- ID also needs to be added for labels to work properly--> <!-- Name should also be made optional to allow fields to be specified that do not take part in forms--> <!ATTLIST IMG src %URL #REQUIRED --URL of image to embed-- alt CDATA #IMPLIED -- for display in place of image-- align %IAlign #IMPLIED --vertical or horizontal alignment-- height %Pixels #IMPLIED --suggested height-- width %Pixels #IMPLIED --suggested width border %Pixels #IMPLIED --suggested link border width-- hspace %Pixels #IMPLIED --suggested horizontal gutter-- vspace $Pixels #IMPLIED --suggested vertical gutter-- usemap %URL #IMPLIED --use client-side image map-- ismap (ismap) #IMPLIED --use server image map-- title CDATA #IMPLIED --advisory title string-- tabindex NUMBER #IMPLIED>
<!ATTLIST APPLET codebase %URL #IMPLIED --code base-- code CDATA #REQUIRED --class file-- name CDATA #IMPLIED --applet name-- alt CDATA #IMPLIED --for display in place of applet-- align %IAlign #IMPLIED --vertical or horizontal alignment-- height %Pixels #IMPLIED --suggested height-- width %Pixels #IMPLIED --suggested width hspace %Pixels #IMPLIED --suggested horizontal gutter-- vspace $Pixels #IMPLIED --suggested vertical gutter-- title CDATA #IMPLIED --advisory title string-- tabindex NUMBER #IMPLIED >
<!ATTLIST INPUT type %InputType TEXT --what kind of widget is needed-- name CDATA #IMPLIED --name of the input-- value CDATA #IMPLIED --value used for form submission-- checked (checked) #IMPLIED --for radio and checkboxes-- size DATA #IMPLIED --specific to each type of field-- maxlength NUMBER #IMPLIED src %URL #IMPLIED --for fields with backgroudn images-- align (t0p|middle|bottom|left|right) top -- image alignment-- title CDATA #IMPLIED --advisory title string-- tabindex NUMBER #IMPLIED notabstop (notabstop) #IMPLIED > <!ATTLIST SELECT name CDATA #REQUIRED size NUMBER #IMPLIED multiple (multiple) #IMPLIED title CDATA #IMPLIED --advisory title string-- tabindex NUMBER #IMPLIED notabstop (notabstop) #IMPLIED >
<!ATTLIST TEXTAREA name CDATA #REQUIRED rows NUMBER #REQUIRED cols NUMBER #REQUIRED title CDATA #IMPLIED --advisory title string-- tabindex NUMBER #IMPLIED >
<!ATTLIST object
%attrs -- id, class, style, lang, dir --
declare (declare) #IMPLIED -- declare but don't instantiate
flag --
classid %URL #IMPLIED -- identifies an implementation --
codebase %URL #IMPLIED -- some systems need an additional
URL --
data %URL #IMPLIED -- reference to object's data --
type CDATA #IMPLIED -- Internet media type for data --
codetype CDATA #IMPLIED -- Internet media type for code --
standby CDATA #IMPLIED -- message to show while loading --
align %Align #IMPLIED -- positioning inside document --
height %Length #IMPLIED -- suggested height --
width %Length #IMPLIED -- suggested width --
border %Length #IMPLIED -- suggested link border width --
hspace %Length #IMPLIED -- suggested horizontal gutter --
vspace %Length #IMPLIED -- suggested vertical gutter --
usemap %URL #IMPLIED -- reference to image map --
shapes (shapes) #IMPLIED -- object has shaped hypertext links
--
name %URL #IMPLIED -- submit as part of form --
title CDATA #IMPLIED -- advisory title string--
tabindex NUMBER #IMPLIED
>
<!-- Added accesskey to anchor and caption.--> <!ATTLIST A name CDATA #IMPLIED --named link end-- href %URL #IMPLIED --URL for linked resource-- rel CDATA #IMPLIED --forward link types-- rev CDATA #IMPLIED --reverse link types-- title CDATA #IMPLIED --advisory title string-- accesskey CDATA #IMPLIED -- tabindex NUMBER #IMPLIED >
<!ATTLIST CAPTION align (top|bottom) #IMPLIED accesskey CDATA #IMPLIED tabindex NUMBER #IMPLIED >