Web Forms 2.0

Abstract

This specification defines Web Forms 2.0, an extension to the forms features found in HTML4's Forms chapter and the corresponding DOM2 HTML interfaces. Web Forms 2.0 applies to both HTML and XHTML user agents. It provides new strongly-typed input fields, new attributes for defining constraints, a repeating model for declarative repeating of form sections, new DOM interfaces, new DOM events for validation and dependency tracking, and XML submission and initialization of forms. It also standardises and codifies existing practice in areas that have not been previously documented, and clarifies some of the interactions of HTML form controls and CSS.

HTML4, XHTML1.1, and the DOM are thus extended in a manner that has a clear migration path from existing HTML forms, leveraging the knowledge authors have built up with their experience with HTML so far.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

If you wish to make comments regarding this document, please send them to whatwg@whatwg.org (subscribe, archives) and public-appformats@w3.org (subscribe, archives). All feedback is welcome.

Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.

Snapshots of the editor's copy of this specification are occasionally submitted to W3C CVS. The latest editor's draft is available on the WHATWG site, and in the WHATWG Subversion repository. Detailed change history can be obtained from the Subversion repository as well.

This specification was originally created, and is still now being developed, outside the W3C. The W3C Web Application Formats Working Group is responsible for this specification's progress along the W3C Recommendation track.

Web Forms 2.0 is not the only approach to making declarative formats for applications and user interfaces that the Web Application Formats Working Group is examining. The working group expects to publish a requirements document for an alternative solution soon.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

• 1. Introduction
  • 1.1. Scope
  • 1.2. Relationship to HTML4
  • 1.3. Relationship to XHTML1.x
  • 1.4. Relationship to HTML5
  • 1.5. Relationship to the W3C DOM
  • 1.6. Relationship to XForms
  • 1.7. Relationship to CSS
  • 1.8. Missing features
  • 1.9. Conformance requirements
  • 1.10. Terminology
  • 1.11. Extensibility
  • 1.12. Security
• 2. Extensions to form control elements
  • 2.1. Introduction for authors
  • 2.2. Existing controls
  • 2.3. Changes to existing controls
  • 2.4. Extensions to the input element
    • 2.4.1. Ranges
    • 2.4.2. Precision
  • 2.5. Extensions to existing attributes
  • 2.6. The pattern attribute
  • 2.7. The required attribute
  • 2.8. The form attribute
  • 2.9. The autocomplete attribute
  • 2.10. The autofocus attribute
  • 2.11. The inputmode attribute
  • 2.12. The datalist element and the list attribute
  • 2.13. The output element
  • 2.14. Extensions to the textarea element
  • 2.15. Extensions to file upload controls
  • 2.16. Extensions to the form element
  • 2.17. Extensions to the submit buttons
  • 2.18. Handling unexpected elements and values
• 3. The repetition model for repeating form controls
  • 3.1. Introduction for authors
    • 3.1.1. More features
    • 3.1.2. Suggestions for authors
    • 3.1.3. Tracking the order of repetition blocks in the submission
    • 3.1.4. What the repetition model can't do
    • 3.1.5. Small example for non-XHTML documents
  • 3.2. Definitions
    • 3.2.1. Repetition templates
    • 3.2.2. Repetition blocks
  • 3.3. New form controls
  • 3.4. The repeat-min and repeat-max attributes
  • 3.5. Event interface for repetition events
  • 3.6. The repetition model
    • 3.6.1. Addition
    • 3.6.2. Removal
    • 3.6.3. Movement of repetition blocks
    • 3.6.4. Initial repetition blocks
    • 3.6.5. Notes for assistive technologies
  • 3.7. Examples
    • 3.7.1. Repeated rows
    • 3.7.2. Nested repeats
• 4. The forms event model
  • 4.1. The click event and input controls
  • 4.2. The change and input events
  • 4.3. Events to enable simpler dependency tracking
  • 4.4. Form validation
  • 4.5. Receiving the results of form submission
  • 4.6. The DOMControlValueChanged event
• 5. Form submission
  • 5.1. Successful form controls
  • 5.2. Handling characters outside the submission character encoding
    • 5.2.1. The _charset_ control
  • 5.3. application/x-www-form-urlencoded
  • 5.4. application/x-www-form+xml: XML submission
  • 5.5. text/plain
  • 5.6. Submitting the encoded form data set
    • 5.6.1. For http: actions
    • 5.6.2. For ftp: actions
    • 5.6.3. For data: actions
    • 5.6.4. For file: actions
    • 5.6.5. For mailto: actions
    • 5.6.6. For javascript: actions
• 6. Fetching data from external resources
  • 6.1. Filling select elements
  • 6.2. Seeding a form with initial values
• 7. Extensions to the HTML Level 2 DOM interfaces
  • 7.1. Additions specific to the HTMLFormElement interface
  • 7.2. Additions specific to the HTMLSelectElement interface
  • 7.3. The HTMLDataListElement interface
  • 7.4. Changes to the HTMLOptionElement interface
  • 7.5. Additions specific to the HTMLFieldsetElement interface
  • 7.6. The HTMLOutputElement interface
  • 7.7. Validation APIs
  • 7.8. New DOM attributes for new content attributes
  • 7.9. Additions specific to the HTMLInputElement interface
  • 7.10. The defaultValue DOM attribute
  • 7.11. Labels
  • 7.12. Firing change events
  • 7.13. Repetition interfaces
• 8. Presentation and rendering
  • 8.1. Styling form controls
  • 8.2. Relation to CSS selectors
  • 8.3. Interaction of the form processing model with CSS
  • 8.4. Interaction of the form processing model with SMIL
• A. XHTML module definition
• B. Attribute summary
• C. Deprecated features
• D. Requirements for declaring interoperability
• References
• Acknowledgements

1. Introduction

This is an update to the forms features found in HTML4's Forms chapter, which are informally referred to as Web Forms 1.0.

Authors have long requested enhancements to HTML4 to support some of their more common needs. Such requests in mailing lists and other forums were examined, and from these sources a set of requirements and design goals were derived:

• Backwards compatibility (where possible).
• Ease of authoring for authors who are familiar with commonly used languages such as HTML and ECMAScript but have limited knowledge about XML, data models, etc.
• Basic data typing, providing new controls for commonly used types so that authors do not need to repeatedly design complicated widgets such as calendars.
• Simpler validation on the client side (while recognizing that server side validation will still be required), with declarative solutions for the common cases, but strong DOM support so that less common cases can easily be handled using scripting.
• Dynamic addition of controls (repeating structures) on the client side without scripting.
• XML submission (although not necessarily arbitrarily structured XML submission).
• The ability to initialize forms from external data sources, so that authors do not have to dynamically rewrite the form content itself to prefill forms, but can instead use static pages with scripts that dynamically generate only the data part.
• This specification should be implementable in full on devices with limited resources.

Not all the desired features have been included in this specification. Future versions may be introduced to address further needs.

This specification does not describe the complete behaviour of an HTML or XHTML user agent. Readers are expected to refer to the existing specifications for the definitions of features that this specification does not change.

1.1. Scope

This specification is limited specifically to incremental improvements to existing wide-spread technologies, namely HTML4 and the DOM, as implemented by browsers prevalent in 2004. It is also intended to be a small step, implementable without overwhelming effort.

Large sweeping changes or new markup languages are therefore out of scope for this specification.

1.2. Relationship to HTML4

This specification clarifies and extends the semantics put forth in [HTML4] for form controls and form submission. It is expected to be implemented in ordinary HTML user agents alongside existing forms technology, and indeed, some of the features described in this draft have been implemented by user agents as ad-hoc, non-standard extensions for many years due to strong market demand.

1.3. Relationship to XHTML1.x

This specification can also be viewed as an extension to [XHTML1]. In particular, some of the features added in this module only apply to XHTML documents; for example, features allowing mixed namespaces.

1.4. Relationship to HTML5

This specification is a prototype for what will become HTML5. It will eventually be merged with other proposals, such as those in the WHATWG Web Applications 1.0 draft, to form the HTML5 and XHTML5 languages.

This specification is written as a set of "patches" to the existing HTML4 and DOM2 specifications. This is not a particularly effective model for a specification. However, rather than rewrite this specification to address this, the intention is to wait until the features are merged into HTML5 before addressing problems that arise from the current frankensteinesque style. [HTML5]

1.5. Relationship to the W3C DOM

This specification clarifies and extends the semantics put forth in [DOM2HTML] for the form control interfaces. These extensions are expected to be implemented in HTML and XHTML user agents that support the DOM.

1.6. Relationship to XForms

This section is aimed at XForms authors and implementors. If you do not plan to use XForms, you may prefer to skip ahead to the next section. Knowledge of XForms is not required to use Web Forms.

This specification is in no way aimed at replacing XForms 1.0 [XForms], nor is it a subset of XForms 1.0.

XForms 1.0 is well suited for describing business logic and data constraints. Web Forms 2.0 aims to simplify the task of transforming XForms 1.0 systems into documents that can be rendered on HTML Web browsers that do not support XForms.

In this transformation model, the XForms processor is a server-side process that converts XForms and XML Schema documents, according to the XForms specification, into HTML and Web Forms documents, which are then processed by the client side Web Forms processor, along with a style sheet for presentation.

The structured XML instance data stored on the server side (e.g. in a database) is converted by the XForms processor into name/value pairs that are then used by the UA to prefill the form. Submission follows the opposite path, with the UA generating name/value pairs and sending them to the XForms processor on the server, which converts them back into structured XML for storage or further processing.

In order to simplify this transformation process, this specification attempts to add some of the functionality of XForms with a minimum impact on the existing, widely implemented forms model. Where appropriate, backwards compatibility, ease of authoring, and ease of implementation have been given priority over theoretical purity.

The following features of XForms have not been addressed:

• The separation of the instance data model, data typing, control interdependencies, and submission information from the content model and interface elements.
• The ability to create arbitrary XML fragments to be filled in before submission.
• The ability to edit local XML files directly. (While technically not defined by the XForms 1.0 specification, UAs have generally implemented such a feature since it is easy to extend the XForms model in that way.)
• Compound data type definitions (schemas).

Many of the less-used features that XForms supports using declarative syntax are, in this specification, handled by using scripting. Some new interfaces are introduced to simplify some of the more tedious tasks.

1.7. Relationship to CSS

This specification does not extend CSS, but it does attempt to clarify some of the interactions between HTML's form features and CSS.

1.8. Missing features

This draft does not address all needs. In addition to the features of XForms that have not been addressed (see above), the following features were considered but rejected for this version of the specification:

• Digital signatures for submissions. This is currently not covered by this specification due to patent concerns. However, it would still be considered for future inclusion if suggestions of how to support it without infringing on known patents were provided.
• DOM interfaces for the creation of new controls that are still able to interact with form submission. This will probably be addressed by the Web Controls 1.0 specification.
• Elements or properties to create tabbed interfaces or "wizard" interfaces. These needs will probably be addressed by the Web Applications 1.0 specification.
• A rich text editing or HTML editing control. This will probably be addressed by the Web Applications 1.0 specification.
• A grid or spreadsheet editing control. This will probably be addressed by the Web Applications 1.0 specification.
• A declarative way of specifying that one list should filter the view of a second list. This need may be addressed in a future version of this specification.

1.9. Conformance requirements

Conformance to this specification is defined for user agents (UAs, implementations) and documents (authors, authoring tools, markup generators). Clauses specify whether they apply to user agents or documents.

User agents could include graphical Web browsers, voice-based mobile devices, automated agents, content indexing robots, and inference tools. In certain user agents, it may be impossible to determine whether a particular conformance criteria is followed or not. For instance, whether indexing robots mark the first option in a select element as selected or not is not detectable. When it is impossible to tell if a UA complies with a particular conformance requirement, that UA is exempt from conforming to that requirement.

Authoring tools and markup generators are conformant if they only produce conformant documents.

As well as sections marked as non-normative, all diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119]

This specification includes by reference the form-related parts of the HTML4, XHTML1.1, DOM2 HTML, DOM3 Core, and DOM3 Events specifications ([HTML4], [XHTML1], [DOM2HTML], [DOM3CORE], [DOM3EVENTS]). Compliant UAs must implement all the forms-related requirements of those specifications, except those modified by this specification, to claim compliance with this one. Implementations may optionally implement only one of HTML4 and XHTML1.1.

Implementations and documents must comply to the W3C Character Model specification. [CHARMOD]

Implementations that do not support scripting (or which have their scripting features disabled) are exempt from supporting the events and DOM interfaces mentioned in this specification. For the parts of this specification that are defined in terms of an events model or in terms of the DOM, such user agents must still act as if events and the DOM were supported.

Scripting can form an integral part of an application. User agents that do not support scripting, or that have scripting disabled, might be unable to fully convey the author's intent.

This specification introduces attributes for setting the maximum size or range of certain values. While user agents should support all possible values, there may be implementation-specific limits.

HTML documents that use the new features described in this specification and that are served over HTTP must be sent as text/html and must use the following DOCTYPE: <!DOCTYPE html>.

XML documents using elements from the XHTML namespace that use the new features described in this specification and that are served over HTTP must be sent using an XML MIME type such as application/xml or application/xhtml+xml and must not be served as text/html. [RFC3023]

These XML documents may contain a DOCTYPE if desired, but this is not required.

Documents that use the new features described in this specification cannot be strictly conforming XHTML1.1 or HTML4 documents, since they contain features not defined in those specifications.

1.10. Terminology

This specification refers to both HTML and XML attributes and DOM attributes, often in the same context. When it is not clear which is being referred to, they are referred to as content attributes for HTML and XML attributes, and DOM attributes for those from the DOM. Similarly, the term "properties" is used for both ECMAScript object properties and CSS properties. When these are ambiguous they are simply qualified as object properties and CSS properties respectively.

Generally, when the specification states that a feature applies to HTML or XHTML, it also includes the other. When a feature specifically only applies to one of the two languages, it is called out explicitly, as in:

Similarly, form elements in XHTML may now be nested (this does not apply to HTML).

Unless otherwise stated, all XML elements defined or mentioned in this specification are in the http://www.w3.org/1999/xhtml namespace, and all attributes defined or mentioned in this specification have no namespace (they are in the per-element partition).

(There are elements from other namespaces in this specification, in particular the XML submission format uses the http://n.whatwg.org/formdata namespace.)

The term form control refers to input, output, select, textarea and button elements. It does not include form, label, datalist, option, optgroup, or fieldset elements.

Form controls are valid when they comply with their constraints, and invalid when they don't. This is distinct from whether form controls have their willValidate attribute set to true, which relates to whether they will be validated, or whether they are successful, which relates to whether they will be submitted.

The terms URI and IRI in normative contexts are used as defined by [RFC3986] and [RFC3987].

When a comparison is said to be case-insensitive, the comparison must be performed using case folding, as described in Unicode. See Unicode 4.0, section 5.18 "Case Mappings", subsection "Caseless Matching". [UNICODE]

1.11. Extensibility

Vendor-specific proprietary extensions to this specification are strongly discouraged. Documents must not use such extensions, as doing so reduces interoperability and fragments the user base, allowing only users of specific user agents to access the content in question.

If markup extensions are needed, they should be done using XML, with elements or attributes from custom namespaces. If DOM extensions are needed, the members should be prefixed by vendor-specific strings to prevent clashes with future versions of this specification. Extensions must be defined so that the use of extensions does not contradict nor cause the non-conformance of functionality defined in the specification.

User agents must treat elements and attributes that they do not understand as semantically neutral; leaving them in the DOM (for DOM processors), and styling them according to CSS (for CSS processors), but not inferring any meaning from them.

1.12. Security

The delivery of Web Forms 2 documents to the user from a remote host and the submission of data from the user to a remote host may be performed using a number of different protocols, and therefore no specific statements can be made regarding the security of those operations.

In general, authors are urged to use a secure transport layer such as TLS when information of a confidential nature is to be transmitted.

On the client side, implementors must be aware of a number of potential attacks. Since it is relatively easy for a hostile Web site to trick users into loading hostile content, for example by sending e-mails claiming to include links to photos of naked girls, users must be confident that a hostile site cannot access confidential information, perform denial-of-service attacks, or hijack the client's host to perform actions on behalf of the user that the user may not approve of.

Confidential information can be stored in several places. Documents from other servers loaded into other browsing contexts (e.g. other windows), documents from other servers that the hostile page has caused to be loaded (of particular concern being pages that include user-specific information using out-of-band authentication and/or authorisation information such as HTTP cookies, HTTP authentication, or the origin host), files on the local system, as well as details of the user's configuration are all potential sources of confidential information.

User agents must therefore implement security mechanisms to block cross-domain accesses (where local files are considered a separate domain). Such mechanisms are referred to as cross-domain scripting security mechanisms. Unfortunately, since it is difficult to predict exactly what attack vectors may exist in such a complex system, and in particular because it depends on the exact feature set of the implementation, this specification does not define the exact mechanism that must be implemented.

In practice user agents implement quite comprehensive cross-domain scripting security mechanisms. Implementation experience has shown that such security mechanisms must, at a minimum, prevent scripts originating from a site at one domain from accessing the properties and methods of any object (in particular, DOM nodes) associated with a page from another domain. Typically, such an access would cause an exception to be raised.

Denial of service attacks are naturally hard to prevent, since they frequently are hard to distinguish from legitimate behaviour. Implementors are encouraged to set arbitrary (although high) limits on what an author can do. For instance, user agents might place a limit on the length of the regular expression pattern allowed in the pattern attribute, if a long expression could be made to take unacceptably long to execute.

Implementations are also asked to consider how otherwise-legitimate UI could be abused by a hostile page. Naturally, since implementations are not restricted in how they implement their interface, no specific guidelines can be given. One example, however, would be the mailto: submission feature. Since a script can artificially submit a form, it is important that the UA not cause each submission to create a new mail window, since this would allow authors to overwhelm the user with windows containing author-specified text, which could act as both a denial-of-service attack, and an annoying advertising technique.

Finally, user agent implementors should prevent pages and scripts in those pages from performing potentially harmful or embarassing actions on behalf of the user without the user's knowledge.

For example, it is recommended that user agents limit the ports to which forms may be submitted, excluding, in particular, ports of well-known protocols like SMTP or telnet. The SMTP port in particular has been used by hostile pages in the past as a target of form submissions for the relaying of spam by unsuspecting users.

Certain actions, including submitting a form to a third-party site and making HTTP GET requests to remote sites (both of which would be blind attacks, assuming the UA implements a cross-domain scripting security mechanism) have been historically allowed, and many sites depend on these features for quite legitimate uses. User agents should allow them.

Servers therefore must also consider security. Servers should never perform non-idempotent actions in response to GET requests, as discussed by the HTTP specification. Servers should also check the Referer header to ensure that only requests from trusted hosts are honoured.

Servers should also consider the client to be untrusted, since in most scenarios requests can be made to hosts by hostile parties directly, bypassing any security logic included in the page nominally intended to perform the submission. Thus servers should perform validation on all submitted data, whether such validation is expected to be performed on the client or not.

Further specific securiy considerations are called out where relevant.

2. Extensions to form control elements

This section describes how Web Forms 2.0 expands the traditional HTML form model to support new types and features.

2.1. Introduction for authors

This subsection is not normative.

One of the big additions to the Web Forms model introduced with this specification is primitive type and validity checking.

Authors can use these new features in various ways. To indicate that a form control expects a particular type of input, authors can specify the types using the type attribute:

<label>E-mail address: <input type="email" name="addr"></label>
<label>Start date: <input type="date" name="start"></label>

To mark a control as required, the required attribute can be used:

<label>Quantity: <input type="number" required="required" name="qty"></label>

To set the range of values that are allowed, the min and max attributes can be used:

<label>Meeting time: <input type="time" min="09:00" max="17:00" name="mt"></label>

Once such constraints have been specified, the user agent will automatically guide the user through any errors he may have made before allowing the form to be submitted.

Authors can hook into this validation system with their scripts. There are several ways to do this.

At any point, scripts can check a control's validity DOM attribute for up to date information on whether a control is valid:

with (document.forms[0]) {
  if (qty.validity.valueMissing) {
    // the quantity control is required but not filled in
  } else if (qty.validity.typeMismatch) {
    // the quantity control is filled in, but it is not a number
  }
}

An author can explicitly set a control as being invalid ("invalid" means that the control's value is not acceptable):

var myControl = document.forms[0].addr;
if (myControl.value == 'a@b.c') {
  myControl.setCustomValidity('You must enter your real address.');
}

Authors can also override the normal user agent error reporting behaviour by hooking into the invalid event:

<label>Home page: <input type="url" name="hp" required="required"
                         oninvalid="alert('You must enter a valid home page address.'); return false;">
</label>

2.2. Existing controls

HTML input elements use the type attribute to specify the data type. In [HTML4], the types (as seen by the server) are as follows:

text

A free-form text field, nominally free of line breaks.

password

A free-form text field for sensitive information, nominally free of line breaks.

checkbox

A set of zero or more values from a predefined list (in the limiting case of the list only containing one value, this is equivalent to a boolean).

radio

An enumerated value.

submit

An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission.

file

An arbitrary file with a MIME type and optionally a file name.

image

A coordinate, relative to a particular image's size, with the extra semantic that it must be the last value selected and initiates form submission.

hidden

An arbitrary string that is not normally displayed to the user.

In addition, HTML also provides a few alternate elements that convey typing semantics similar to the above types, but use different content models:

select

An enumerated value, much like the radio type.

select multiple

A set of zero or more values from a predefined list, much like the checkbox type.

textarea

A free-form text field, nominally with no line break restrictions.

button

An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission, much like the submit type but with a richer content model.

The difference between the checkbox and radio types and their select and select multiple counterparts is that for the select variants the values are only available through a single composite control, whereas for the checkbox and radio types the controls representing each value may be individually placed around the document.

There are also two button types (available on both input and button elements) that are never submitted: button and reset.

This specification includes all of these types, their semantics, and their processing rules, by reference, for backwards compatibility.

These types are useful, but limited. This specification expands the list to cover more specific data types, and introduces attributes that are designed to constrain data entry or other aspects of the UA's behaviour.

2.3. Changes to existing controls

In addition to the attributes described below, some changes are made to the content model of HTML form elements to take into account scripting needs. Specifically, the form, legend, select, and optgroup elements may now be empty. However, with the exception of the form element, authors should avoid allowing any of these elements to be both empty and visible for any noticable period, as it is likely to confuse users. In HTML4, those elements always required at least one element child, or, in the case of legend, at least one character of text.

Also, as controls no longer need to be contained within their form element to be associated with it, authors may prefer to declare their forms in advance, at the top of their documents. The form element is therefore allowed in the head element of XHTML documents, although only when the form element is empty. (This does not apply to HTML, where a <form> tag has always implied the end of any unclosed head element and the beginning of the body.)

Similarly, form elements in XHTML may now be nested (this does not apply to HTML, where a <form> start tag nested in a form element is typically ignored by UAs). Form controls by default associate with their nearest form ancestor. Forms are not semantically related to ancestor forms in any way, and do not share attributes or form controls or events (except insofar as events bubble up the DOM).

The children of a form element must be block-level elements, unless one of the ancestors of the form element is an element other than div whose content model includes both block- and inline-level content, in which case either block-level or inline-level content is allowed (but not both). input elements of type hidden may be placed anywhere (both in inline contexts and block contexts).

The form and select elements are extended with data attributes for fetching values and options from external resources.

Radio buttons in sets where none of the buttons are marked as checked must all be initially left unchecked by the UA (which differs from the behavior described in [RFC1866], but more accurately represents common implementation and author needs). Authors are recommended to always have one radio button selected. Having no radio buttons selected is considered very poor UI.

Radio buttons in sets where more than one button is marked as checked must all be initially left unchecked by the UA except for the last radio button marked as checked. Each time a checked radio button is inserted into the document, the UA must uncheck all the other radio buttons in that set in the document. Authors must not mark more than one radio button per set as being checked.

Previous versions of Web Forms were inconsistent about whether the first option element of a single-select select element with no otherwise-selected items should be automatically selected. According to [RFC1866], it should be, and according to [HTML4] it was undefined. User agents implementing this specification must select the first (non-disabled) option element of a single-select select element with no otherwise-selected items. (If all the items are disabled or there are no items, then no item will be selected.)

The optgroup element may now be nested inside other optgroup elements.

The label element's exact default presentation and behaviour should match the platform's label behaviour. For example, on platforms where clicking a checkbox label checks the checkbox, clicking a label element should cause a click event to be synthesised and fired at the checkbox. In any case, events targeted at form controls (or other interactive elements, e.g. links) within a label must not be handled by the label itself.

User agents may establish a button in each form as being the form's default button. (This should be the first submit button in the form, but UAs may pick another button if another would be more appropriate for the platform.) If the platform supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then when doing so the form's default submit button must be the one used to initiate form submission (and it will therefore probably be successful). To initiate for submission in such a case, the user agent must fire a click event at the button's element, as if the user had clicked the button himself.

Consequently, if the default button is disabled, the form must not be submitted when such an implicit submission mechanism is used. (The default action of a click on a disabled button is to do nothing.)

If there is no submit button, then the implicit submission mechanism must submit the form as if there was an enabled, unnamed, default button. No click event is fired in this case.

Submit buttons can be associated with multiple forms, but only ever submit to the first form they are associated with. A default button for one form, therefore, could submit a different form when implicitly invoked than the form for which it is a default button. (This, however, is an edge case.)

For checkbox and radio form controls, the value attribute defaults to the literal string on, so that if the value content attribute is not specified then the value DOM attribute (and the value used for submission when the controls are checked) is "on". For other controls the default is the empty string.

The attributes defined in this specification as accepting a fixed set of values (e.g. type) must be compared to those values using a case-insensitive literal comparison. Whitespace must not be trimmed from attribute values to make that comparison.

Whitespace must also not be trimmed from any other attributes (e.g. the value attribute).

Whitespace can get trimmed by the parser for other reasons; e.g. if an XML DTD is used, the XML specification can require certain attributes to have whitespace trimmed.

2.4. Extensions to the input element

Several new values are introduced for the type attribute. As with the older types, UAs are recommended to show specialized widgets for these types, instead of requiring that the user enter the data into a text field.

The formats described below are those that UAs must use in the DOM and when submitting the data. They do not necessarily represent what the user is expected to type. User agents are expected to show suitable user interfaces for each of these types (e.g. using the user's locale settings). It is the UA's responsibility to convert the user's input into the specified format.

For most of these types, min, max and step attributes can be applied to restrict the range of numbers that apply.

datetime

A date and time (year, month, day, hour, minute, second, fractions of a second) encoded according to ISO 8601 [ISO8601] with the time zone set to UTC: four or more digits (0 to 9) representing the year, a hyphen (U+002D), two digits for the month, a hyphen, two digits for the day, a literal "T", two digits for the hour, a colon (U+003A), two digits for the minute, optionally a colon and two digits for the second, optionally (if the seconds are present) a period (U+002E) and one or more digits for the fraction of a second, and finally a mandatory literal "Z". All the numbers must be in base ten and zero-padded if necessary. If the seconds are omitted, they must be assumed to be zero. If the fraction is omitted, it must be assumed to be zero as well. For instance: 1995-12-31T23:59:59.99Z or, representing the time 10 milliseconds later, 1996-01-01T00:00Z. The step attribute specifies the precision in seconds, defaulting to 60 (one minute).

User agents are expected to show an appropriate widget. UAs may display the time in whatever time zone is appropriate for the user, but should be clear to the user that the time is globally defined, not time-zone dependent. The submitted date and time must be in the UTC time zone.

datetime-local

A date and time (year, month, day, hour, minute, second, fractions of a second) encoded according to ISO 8601 [ISO8601], with no time zone information: four or more digits (0 to 9) representing the year, a hyphen (U+002D), two digits for the month, a hyphen, two digits for the day, a literal "T", two digits for the hour, a colon (U+003A), two digits for the minute, optionally a colon and two digits for the second, and optionally (if the seconds are present) a period (U+002E) and one or more digits for the fraction of a second. All the numbers must be in base ten and zero-padded if necessary. If the seconds are omitted, they must be assumed to be zero. If the fraction is omitted, it must be assumed to be zero as well. For instance: 1995-12-31T23:59:59.99 or, representing the time 10 milliseconds later, 1996-01-01T00:00. The step attribute specifies the precision in seconds, defaulting to 60 (one minute).

date

A date (year, month, day) encoded according to ISO 8601 [ISO8601]: four or more digits (0 to 9) representing the year, a hyphen (U+002D), two digits for the month, a hyphen, and two digits for the day. All the numbers must be in base ten and zero padded if necessary. For instance: 1995-12-31. The step attribute specifies the precision in days, defaulting to 1. User agents are expected to show an appropriate widget, such as a datepicker.

month

A date consisting of a year and a month encoded according to ISO 8601 [ISO8601]: four or more digits (0 to 9) representing the year, a hyphen (U+002D), and two digits for the month, zero-padded if necessary. All the numbers must be in base ten. For instance: 1995-12. The step attribute specifies the precision in months, defaulting to 1. This type is used most frequently for credit card expiry dates.

week

A date consisting of a year and a week number encoded according to ISO 8601 [ISO8601]: four or more digits (0 to 9) representing the year, a hyphen (U+002D), a literal "W", and two digits for the week, zero-padded if necessary. All the numbers must be in base ten. The week number must be a number greater than or equal to 01. Week 01 of a given year is the week containing the 4th of January; weeks start on Monday. For instance: 2005-W52 is the week that ends on Sunday the first of January, 2006. The step attribute specifies the precision in weeks, defaulting to 1. This type is used most frequently for dates in European industry.

time

A time (hour, minute, seconds, fractional seconds) encoded according to ISO 8601 [ISO8601] with no time zone: two digits (0-9) for the hour, a colon (U+003A), two digits for the minute, optionally a colon and two digits for the second, and optionally (if the seconds are present) a period (U+002E) and one or more digits for the fraction of a second. All the numbers must be in base ten and zero-padded if necessary. If the seconds are omitted, they must be assumed to be zero. If the fraction is omitted, it must be assumed to be zero as well. For instance: 23:59:00.00000 or 00:00:05. The step attribute specifies the precision in seconds, defaulting to 60. Times must be greater than or equal to 0 and must be less than 24 hours, in addition to any tighter restrictions placed on the control by the min and max attributes. Note that this type is not an elapsed time data type.

User agents are expected to show an appropriate widget, such as a clock. UAs should make it clear to the user that the time does not carry any time zone information.

number

A numerical value. The step attribute specifies the precision, defaulting to 1.

Numbers must be submitted as a significand followed by an optional exponent. The significand is an optional minus sign (U+002D, "-"), an integer, and optionally a decimal point (U+002E, ".") and an integer representing the fractional part. The exponent is a lowercase literal letter "e", an optional minus sign, and an integer representing the index of a power of ten with which to multiply the significand to get the actual number. Integers are one or more decimal digits. If the exponent part is omitted its index of a power of ten must be assumed to be zero.

For example, negative-root-two, to 32 significant figures, would be -1.4142135623730950488016887242097e0, the radius of the earth given in furlongs, to an arbitrary precision, would be 3.17e4, and the answer to the life, the universe and everything could be any of (amongst others) 42, 0042.000, 42e0, 4.2e1, or 420e-1.

This format is designed to be compatible with scanf(3)'s %f format, ECMAScript's parseFloat, and similar parsers while being easier to parse than some other floating point syntaxes that are also compatible with those parsers.

The strings +0, 0e+0, and +1e+3 are all invalid numbers (the minus sign cannot be replaced by a plus sign for non-negative numbers, it must simply be omitted). Similarly, .42e2 is invalid (there must be at least one digit before the decimal point). UAs must not submit numbers in invalid formats (whatever the user might enter).

The submission format is not intended to be the format seen and used by users. UAs may use whatever format and UI is appropriate for user interaction; the description above is simply the submission format.

This input type is not appropriate for things like telephone numbers or credit card numbers. Despite their names, those aren't really numbers — the telephone number "65000" is not equivalent to "65e3", but "65000", "65e3", "6.5e4", "65000.00", etc, are all possible ways that a browser would submit that number. For "numbers" that are really specially formatted strings, like telephone numbers, social security numbers, credit card numbers, etc, authors should use the "text" input type, possibly with an appropriate pattern.

range

Same as number, but indicates that the exact value is not important, letting UAs provide a simpler interface than they do for number. For instance, visual UAs may use a slider control. The step, min, and max attributes still apply. For this type, step defaults to 1, min defaults to 0, max defaults to 100, and value defaults to the min value.

Volume controls and brightness controls would be good examples of "range" data controls.

email

An e-mail address, following the format of the addr-spec token defined in RFC 2822 section 3.4.1 [RFC2822], but excluding the CFWS subtoken everywhere, and excluding the FWS subtoken everywhere except in the quoted-string subtoken. UAs could, for example, offer e-mail addresses from the user's address book. (See below for notes on IDN.)

url

An IRI, as defined by [RFC3987] (the IRI token, defined in RFC 3987 section 2.2). UAs could, for example, offer the user URIs from his bookmarks. (See below for notes on IDN.) The value is called url (as opposed to iri or uri) for consistency with CSS syntax and because it is generally felt authors are more familiar with the term "URL" than the other, more technically correct terms.

Relative URIs and IRIs do not match the IRI token mentioned above. Only absolute addresses (potentially with fragment identifiers) are valid values for this input type. Of course, this does not prevent a user agent from allowing users to enter relative or incomplete values, but such values would have to be expanded to complete addresses before the control's isTypeMismatch flag is cleared.

Any string that matches the IRI token must be accepted as a valid value by user agents. For example, user agents are not required to check that given values are in full logical order.

Four other new types, add, remove, move-up and move-down, have been introduced. They are defined as part of the repeating form controls model.

The email and url controls may contain IDN domains. [RFC3490] These should be sent in their original (full-Unicode) characters, not IDNA-encoded. (Authors can use the pattern pattern="[\x00-\x7F]+" to indicate that only ASCII-based domain names are to be allowed.) Time-related controls must ignore leap seconds. Date-related controls must submit dates according to the proleptic Gregorian calendar, and must support dates according to this calendar starting at 0001-01-01. (This does not preclude user agents using more historically appropriate calendars for past dates, e.g. switching to the Julian calendar before the mid-18th century, nor does it preclude them from using calendars more appropriate to the user's locale, e.g. using the Chinese calendar.)

A control is said to have no value selected if its value is the empty string. File controls are said to have no value selected if no files have been selected.

By default, all of these new types (except range), just like the types from HTML4, must have no value selected unless a default value in a valid format is provided using the value attribute. For all controls, if a value is specified but it is not in a format that is valid for the type (where the valid types are the same as the valid submission types described above) then the defaultValue DOM attribute has the specified value, and the control is left with the value it would have had if the value attribute had not been specified (namely, no value selected, except for range controls, which have the min value selected).

User agents may allow users to set a control to its "no value selected" state, but are not required to do so.

Controls with no value selected do not need to match the format appropriate for their type. (Although if they are required controls, they will stop submission for that reason instead.)

If a control has its type attribute changed to another type, then the user agent must reinterpret the current value (given by the value DOM attribute) and the default value (given by the value content attribute and the defaultValue DOM attribute) in light of the new type. Values that no longer match the format allowed for the control must be handled as described in the error handling section.

<form action="..." method="post" onsubmit="verify(event)">
 <p>
  <label>
   Quantity:
   <input name="count" type="number" min="0" max="99" value="1" />
  </label>
 </p>
 <p>
  <label for="time1"> Preferred delivery time: </label>
  <input id="time1" name="time1" type="time" min="08:00" max="17:00" value="08:00" /> —
  <input id="time2" name="time2" type="time" min="08:00" max="17:00" value="17:00" />
 </p>
 <script type="text/javascript">
  function verify(event) {
    // check that time1 is smaller than time2, otherwise, swap them
    if (event.target.time1.value >= event.target.time2.value) { // ISO 8601 times are string-comparison safe.
      var time2Value = event.target.time2.value;
      event.target.time2.value = event.target.time1.value;
      event.target.time1.value = time2Value;
    }
  }
 </script>
</form>

Servers should still perform type-checking on submitted data, as malicious users or rogue user agents might submit data intended to bypass this client-side type-checking. Validation done via script may also be easily bypassed if the user has disabled scripting. Additionally, legacy user agents do not support the validation features described in this specification and will therefore submit data that has not been checked.

The size attribute of the input element is deprecated in favor of using CSS to specify the layout of the form.

2.4.1. Ranges

To limit the range of values allowed by some of the above types, two new attributes are introduced, which apply to the date-related, time-related, numeric, and file upload types:

min

Gives the minimum value (inclusive) of the control, in the format specified for the relevant type. Values for the control less than the minimum value are out of range (rangeUnderflow). If absent, or if the minimum value is not in exactly the expected format, there is no minimum restriction, except for the range and file types, where the default is zero.

max

Gives the maximum value (inclusive) of the control, in the format specified for the relevant type. Values for the control greater than the maximum value are out of range (rangeOverflow). If absent, or if the maximum value is not in exactly the expected format, there is no maximum restriction (beyond those intrinsic to the type), except for the range type, where the default is 100, and the file type, where the default is 1.

For date, time and numeric controls, the values indicate the allowed range. For file upload controls, the values indicate the allowed number of files.

The typeMismatch flag is used for controls whose values do not match their types, and the rangeUnderflow and rangeOverflow flags are used for controls whose values are outside the allowed range.

A control with a max less than its min can never fulfill both conditions when it has a value (since that value will always either underflow or overflow the allowed range) and thus must block its forms from being submitted. This does not make the document non-conformant.

The exact values allowed by min and max depend on the type attribute. For numeric types (number and range) the value must exactly match the number type described above. For file types it must be a sequence of digits 0-9, treated as a base ten integer. For date and time types it must match the relevant format mentioned for that type, all fields having the right number of digits, with the right separating punctuation.

If a control has its type attribute changed to another type, then the user agent must reinterpret the min and max attributes. If an attribute has an invalid value according to the new type, then the appropriate default must be used (and not, e.g., the default appropriate for the previous type). Control values that no longer match the range allowed for the control must be handled as described in the error handling section.

<input type="time" min="50.00">

<input type="time" min="22:00">
<input type="time" min="22:00:50.0001">

2.4.2. Precision

The step attribute controls the precision allowed for the date-related, time-related, and numeric types.

For the control to be valid, the control's value must be an integral number of steps from the min value, or, if there is no min attribute, the max value, or if there is neither attribute, from the zero point.

The zero point for datetime controls is 1970-01-01T00:00:00.0Z, for datetime-local is 1970-01-01T00:00:00.0, for date controls is 1970-01-01, for month controls is 1970-01, for week controls is 1970-W01 (the week starting 1969-12-29 and containing 1970-01-01), and for time controls is 00:00.

For time controls, the value of the step attribute is in seconds, although it may be a fractional number as well to allow fractional times. The format of the step attribute is the number format described above, except that the value must be greater than zero. The default value of the step attribute for datetime, datetime-local and time controls is 60 (one minute).

<input type="datetime" step="120" name="start">

<input type="time" min="00:00:15.20" name="t">

For date controls, the value of the step attribute is in days, weeks, or months, for the date, week, and month types respectively. The format is a non-negative integer; one or more digits 0-9 interpreted as base ten. If the step is zero, it is interpreted as the default. The default for the step attribute for these control types is 1.

<input type="date" min="1900-01-07" step="7" name="sunday">

For numeric controls (number and range), the format of the step attribute is the number format described above, except that the value must be greater than zero. For numeric controls, the default value of the step attribute is 1.

<input type="range" step="2" name="evenN">

<input type="range" step=".1" name="n">

In addition, for any of the types, the literal value any may be used as the value of the step attribute. This keyword indicates that any value may be used (within the bounds of other restrictions placed on the control).

<input type="number" step="any" name="n">

The stepMismatch flag is used for controls whose values are not one of the values allowed by the step attribute. However, UAs may silently round the number to the nearest value allowed by the step attribute instead of reporting a stepMismatch validation error. (Such rounding may make the value out of range, causing, for instance, a rangeOverflow validation error.)

If the author specified step is too small for the UA to handle (for example, 1e-9999999 would probably underflow most implementations) then the UA should treat the value as any. If the given step value is not one of the allowed values, then the default is used.

User agents are recommended to never convert user- and author-supplied values to their binary numeric representation, keeping the values in string form at all times and performing comparisons in that form. This ensures that UAs are able to handle arbitrarily large numbers without risking data loss due to rounding in the decimal-to-binary conversion.

If a UA needs to round a number to its nearest binary equivalent, as, for example, when converting a user-supplied decimal number and an author-supplied minimum in order to compare them to establish validity (ignoring the suggestion above to do these comparisons in string form), algorithms equivalent to those specified in ECMA262 sections 9.3.1 ("ToNumber Applied to the String Type") and 8.5 ("The Number type") should be used (possibly after suitably altering the algorithms to handle numbers of the range that the UA can support). [ECMA262]

If a control has its type attribute changed to another type, then the user agent must reinterpret the step attribute. If it has an invalid value according to the new type, then the new appropriate default must be used. Control values that no longer match the precision allowed for the control must be handled as described in the error handling section.

2.5. Extensions to existing attributes

In addition to the new attributes given in this section, some existing attributes from [HTML4] are clarified and extended below. These, and other attributes from HTML4, continue having the same semantics as described in HTML4 unless specified otherwise.

accesskey

UAs may now support the accesskey attribute on select elements (and must at a minimum support the relevant DOM attribute).

The accesskey attribute on label elements must act the same way as it would if specified on the associated element directly.

disabled

The disabled attribute applies to all form controls except the output element, and also to the fieldset, option, and optgroup elements. In HTML4 the disabled attribute did not apply to the fieldset element.

When applied to a fieldset element it overrides the disabled attributes of any descendent form controls (regardless of whether they are associated with the same form). In other words, a form control shall be disabled if it has its disabled attribute set, or if any of its ancestor fieldset elements have their disabled attribute set.

maxlength

This attribute applies to text, password, url, and email input types, and textarea elements. In particular, it does not apply to the date-related, time-related, and numeric control types. In HTML4, this attribute only applied to the text and password types.

For text input controls it specifies the maximum length of the input, in terms of numbers of code points. [CHARMOD].

A newline in a textarea's value must count as two code points for maxlength processing (because newlines in textareas are submitted as U+000D U+000A). This includes the implied newlines that are added for submission when the wrap attribute has the value hard.

Authors are discouraged from using maxlength on url and email controls unless the server side processor actually has a limit on the size of data fields it can usefully process. Valid URIs and e-mail addresses in particular can often be surprisingly long.

The tooLong flag is used when this attribute is specified on a text, password, url, email or textarea control and the control has more than the specified number of code points and the value doesn't match the control's default value.

Servers should still expect to receive, and must be able to cope with, content larger than allowed by the maxlength attribute, in order to deal with malicious or non-conforming clients.

This attribute must not affect the initial value (the DOM defaultValue attribute). It must only affect what the user may enter and whether a validity error is flagged during validation.

If the maxlength attribute has a value that is less than the length required for a valid value of the given type, for example:

<input type="email" maxlength="1" name="test"/>

...then the control can only be valid if it is has no value selected (unless, of course, it is a required control, in which case it can never be valid).

name

Some names (all starting with the string "Ecom_") are reserved by [RFC3106]. Authors must not use names starting with the string "Ecom_" in ways that conflict with RFC3106.

readonly

This attribute applies only to text, password, email, url, date-related, time-related, and number input types, as well as the textarea element. Specifically, it does not apply to radio buttons, checkboxes, file upload controls, range controls, select elements, or any of the button types; the interface concept of "readonly" values does not apply to button-like user interfaces.

Other attributes not listed in this specification retain the same semantics as in [HTML4].

2.6. The pattern attribute

For the text, password, email, and url types of the input element, and for the textarea element, the pattern attribute specifies a pattern that the control value must match.

When specified, the pattern attribute contains a regular expression that the control's value must match before the form may be submitted (patternMismatch).

<label> Credit Card Number:
 <input type="text" pattern="[0-9]{13,16}" name="cc" />
</label>

The regular expression language used for this attribute is the same as that defined in [ECMA262], except that the pattern attribute must match the entire value, not just any subset (somewhat as if it implied a ^(?: at the start of the pattern and a )$ at the end). The pattern must be compiled with the global, ignoreCase, and multiline flags disabled (see ECMA262, sections 15.10.7.2 through 15.10.7.4). If the attribute is omitted then the control has no pattern restriction.

The / character is not special in the pattern attribute. The two attributes pattern="/etc/.+" and pattern="\/etc\/.+" are therefore equivalent.

In the case of the email and url types, the pattern attribute specifies a pattern that must be matched in addition to the value matching the generic pattern relevant for the control. If the pattern given by the attribute specifies a pattern that is incompatible with the grammar of the control type, as in the example below, then the control could never be satisfied. (A document containing such a situation is not technically non-conformant, but it is of dubious semantic use.)

<form>
 <p>
  This form could never be submitted, as the following required control
  can never be satisfied:
  <input type="url" pattern="[^:]+" required="required" name="test"/>
 </p>
</form>

When the value doesn't match the control's type, the typeMismatch flag must be set; when the value doesn't match the pattern, the patternMismatch flag must be set. If the value matches neither the control's type nor the control's pattern, both flags must be set.

When the pattern is not a valid regular expression, it is ignored for the purposes of validation, as if it wasn't specified.

Controls with no value selected do not need to match their pattern. (Although if they are required controls, they will stop submission for that reason anyway.)

If the pattern attribute is present but empty, it doesn't match any value, and thus the patternMismatch flag shall be set whenever the control's value isn't empty.

Authors should include a description of the pattern in the title attribute. User agents may use the contents of this attribute when informing the user that the pattern is not matched, or at any other suitable time, such as in a tooltip or read out by assistive technology when the control gains focus.

<label> Part number:
 <input pattern="[0-9][A-Z]{3}" name="part"
        title="A part number is a digit followed by three uppercase letters."/>
</label>

When a control has a pattern attribute, the title attribute, if used, must describe the pattern. Additional information could also be included, so long as it assists the user in filling in the control. Otherwise, assistive technology would be impaired.

For instance, if the title attribute contained the caption of the control, assistive technology could end up saying something like The text you have entered does not match the required pattern. Birthday, which is not useful.

UAs may still show the title in non-error situations (for example, as a tooltip when hovering over the control), so authors should be careful not to word titles as if an error has necessarily occurred.

2.7. The required attribute

Form controls can have the required attribute specified, to indicate that the user must enter a value into the form control before submitting the form.

The required attribute applies to all form controls except controls with the type hidden, image inputs, buttons (submit, move-up, etc), and select and output elements. For disabled or readonly controls, the attribute has no effect.

The valueMissing flag is used for form controls marked as required that do not have values.

For checkboxes, the required attribute shall only be satisfied when one or more of the checkboxes with that name in that form are checked.

For radio buttons, the required attribute shall only be satisfied when exactly one of the radio buttons in that radio group is checked.

For file upload controls, the required attribute shall only be satisfied if at least one valid file is selected, regardless of the min and max attributes.

<ul>
  <li><label> Name: <input type="text" name="name" required="required" /></label></li>
  <li><label> Comment: <input type="text" name="comment" /></label></li>
</ul>

For other controls, any non-empty value shall satisfy the required condition, including a simple whitespace character.

2.8. The form attribute

All form controls as well as the fieldset element may have the form attribute specified. The form attribute gives a space-separated list of IDs of form elements that the form control is to be associated with, and overrides the relationship between the form control and any ancestor form element.

Any of the IDs in the space-separated list that do not identify an element in the document, or that identify an element that is not an HTML form element, must be ignored. Setting an element's form attribute to the empty string (or to a string consisting only of IDs that do not correctly identify form elements) just disassociates the form control from its form, leaving it unassociated with any form.

When set on a fieldset element, this attribute also changes the association of any descendent form controls, unless they have form attributes of their own or are contained inside forms that are themselves descendants of the fieldset element.

In other words, user agents must associated form controls and fieldsets with the forms given in their form attribute, or, if they don't have one, with the nearest ancestor form element or the forms given in the form attribute of the nearest fieldset element with a form attribute, whichever is the nearest. If none of those apply, the element is not associated with any form.

When forms are submitted, are reset, or have their form controls enumerated through the DOM, only those controls associated with the form are taken into account. A control can be associated with more than one form at a time. Submit buttons and image controls must only submit the first form they are associated with. Reset buttons must reset all the forms they are associated with.

A form attribute that specifies an ID that occurs multiple times in a document must select the same form as would be selected by the getElementById() method for that ID ([DOM3CORE]). (That is, the exact behaviour is undefined, but must be the same as if the getElementById() method was used.)

If a form is specified multiple times in the form attribute, all occurrences but the first must be ignored. (An element can only be associated with a form once.) A form must not be specified more than once in a form attribute.

<table>
 <thead>
  <tr>
   <th>Name</th>
   <th>Value</th>
   <th>Action</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>
    <form id="edit1" action="/edit" method="post">
     <input type="hidden" name="id" value="1"/>
     <input type="text" name="name" value="First Row"/>
    </form>
   </td>
   <td>
    <input form="edit1" type="text" name="value"/>
   </td>
   <td>
    <input form="edit1" type="submit" name="Edit"/>
   </td>
  </tr>
  <tr>
   <td>
    <form id="edit2" action="/edit" method="post">
     <input type="hidden" name="id" value="2"/>
     <input type="text" name="name" value="Second Row"/>
    </form>
   </td>
   <td>
    <input form="edit2" type="text" name="value"/>
   </td>
   <td>
    <input form="edit2" type="submit" name="Edit"/>
   </td>
  </tr>
 </tbody>
</table>

<form action="test.cgi">
 <input type="text" name="q" form="fg fy">
 <input type="submit" name="t" value="Test">
</form>
<form id="fg" action="google.cgi"><input type="submit" value="Google"></form>
<form id="fy" action="yahoo.cgi"><input type="submit" value="Yahoo"></form>

2.9. The autocomplete attribute

The autocomplete attribute applies to the text, password, date-related, time-related, numeric, email, and url controls. The attribute takes two values, on and off. The default, when the attribute is not specified, is on.

The off value means that the control's input data is either particularily sensitive (for example the activation code for a nuclear weapon) or that it is a value that will never be reused (for example a one-time-key for a bank login) and indicates that the user should therefore explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for him. The on value indicates that the value is not particularily sensitive and the user should expect to be able to rely on his UA to remember values he has entered for that control.

When a control has its autocomplete attribute set to a value other than off, or when the attribute is omitted, the UA may store the value entered by the user so that if the user returns to the page, the UA can prefill the form. When a control has its autocomplete attribute set to off, the UA should not remember that control's value.

This specification does not define the autocompletion mechanism. UAs may implement any system within the conformance criteria of this specification, taking into account security and privacy concerns.

<p>Account: <input type="text" name="ac" autocomplete="off" /></p>
<p>PIN: <input type="text" name="pin" autocomplete="off" /></p>

A UA may allow the user to disable support for this attribute. Support for the attribute should be enabled by default, and the ability to disable support should not be trivially accessible, as there are significant security implications for the user if support for this attribute is disabled.

In practice, this attribute is required by many banking institutions, who insist that UAs with auto-complete features implement it before supporting them on their Web sites. For this reason, it is implemented by most major Web browsers already, and has been for many years.

2.10. The autofocus attribute

Any form control (except hidden and output controls) can have an autofocus attribute specified.

When a form control is inserted into a document, the UA must check to see if it has this attribute set. If it does, and the control is not disabled, and it is of a type normally focusable in the user's operating environment, then the UA should focus the control, as if the control's focus() method was invoked. UAs with a viewport should also scroll the document enough to make the control visible, even if it is not of a type normally focusable.

Authors must not set the autofocus attribute on multiple enabled elements in a document. If multiple elements with the autofocus attribute set are inserted into a document, each one will be processed as described above, as they are inserted. This means that during document load, for example, the last focusable form control in document order with the attribute set will end up with the focus.

UAs may ignore this attribute if the user has indicated (for example, by starting to type in a form control) that he does not wish focus to be changed.

The value of the attribute, if set, should be autofocus. The autofocus DOM attribute must return true when the content attribute is present (regardless of its value, even if it is the empty string), and false when it is absent. Setting the DOM attribute to true must set the content attribute to the value autofocus. Setting the DOM attribute to false must remove the content attribute.

<input maxlength="256" name="q" value="" autofocus="autofocus">
<input type="submit" value="Search">

In HTML, the minimised form may be used (just autofocus instead of autofocus="autofocus").

<input autofocus>

Focusing the control does not imply that the UA must focus the browser window if it has lost focus.

2.11. The inputmode attribute

The inputmode attribute applies to the input element when it has a type attribute of text, password, email, or url, and to the textarea element.

This attribute is defined to be exactly equivalent to the inputmode attribute defined in the XForms 1.0 specification (sections E1 through E3.2) [XForms].

2.12. The datalist element and the list attribute

For the text, email, url, date-related, time-related, and numeric types of the input element, a new attribute list is introduced to point to a list of values that the UA should offer to the user in addition to allowing the user to pick an arbitrary value.

To complement the new list attribute, a datalist element is introduced. This element has two roles: it provides a list of data values, in the form of a list of option elements, and it may be used to provide fallback content for user agents that do not support this specification.

If the UA supports this element, it should not be displayed. In CSS-aware user agents, this should be achieved by including the following rules, or their equivalent, in the UA's user agent style sheet:

@namespace xh url(http://www.w3.org/1999/xhtml);
xh|datalist { display: none; }

When a control has a list attribute, it specifies an element from which to derive the list of author-specified autocompletion values for the control.

The element specified is the one that would be returned when calling getElementById() with the value of the list attribute as the argument, if the returned value is an element node with either the local name datalist or the local name select, and (for XHTML) with the XHTML namespace. If the attribute is present but either specifies an ID that is not in the document, or specifies an element that is not an (X)HTML datalist or select, then it must be ignored.

The list of autocompletion values shall be given by the list of elements that would be found by calling getElementsByTagName() with the local name option on the element specified, if any (or, in XHTML documents, the list of elements that would be found by calling getElementsByTagNameNS() with the same local name and the XHTML namespace).

For each element in this list, if the element is not marked as disabled, the autocompletion value is either the value of its value content attribute, or, if that attribute is absent, the value of its text DOM attribute. The UA may use the label attribute to annotate the value in its interface. If the element is marked as disabled, if the autocompletion value is the empty string, or if the autocompletion value is not a valid value for the control's type (for example, 20 is not a valid value for a datetime control) then it must be ignored.

The author-specified list of predefined values may be augmented by the UA's own autocompletion logic. For example, the UA may remember previous values that the user has entered.

UAs are encouraged to filter the autocomplete list and only show values that would pass validation (e.g. if the form control has a pattern attribute, only showing autocomplete values that match the pattern).

Authors must only use empty option elements or elements that would be allowed in the datalist element's parent as children of datalist elements. datalist elements may be used wherever block-level elements are allowed and wherever select elements are allowed.

Controls inside datalist elements must never be successful. (They must still, however, be associated with their form.)

The datalist element may be prefilled from an external file with the data attribute.

The selected content attribute and the form, selected, defaultSelected, and index DOM attributes on option elements must have no effect on the input and datalist elements when option elements are used in this context.

<input type="url" name="location" list="urls">
<datalist id="urls">
 <option label="MIME: Format of Internet Message Bodies" value="http://www.ietf.org/rfc/rfc2045">
 <option label="HTML 4.01 Specification" value="http://www.w3.org/TR/html4/">
 <option label="Form Controls" value="http://www.w3.org/TR/xforms/slice8.html#ui-commonelems-hint">
 <option label="Scalable Vector Graphics (SVG) 1.1 Specification" value="http://www.w3.org/TR/SVG/">
 <option label="Feature Sets - SVG 1.1 - 20030114" value="http://www.w3.org/TR/SVG/feature.html">
 <option label="The Single UNIX Specification, Version 3" value="http://www.unix-systems.org/version3/">
</datalist>

<p>
 <label>
  Enter a breed:
  <input type="text" name="breed" list="breeds">
  <datalist id="breeds">
   <option value="Abyssinian">
   <option value="Alpaca">
   <!-- ... -->
  </datalist>
 </label>
</p>

<p>
 <label>
  Enter a breed:
  <input type="text" name="breed" list="breeds">
 </label>
 <datalist id="breeds">
  <label>
   or select one from the list:
   <select name="breed">
    <option value=""> (none selected)
    <option>Abyssinian
    <option>Alpaca
    <!-- ... -->
   </select>
  </label>
 </datalist>
</p>

<input type="range" min="-100" max="100" value="0" step="10" name="power" list="powers">
<datalist id="powers">
 <option value="0">
 <option value="-30">
 <option value="30">
 <option value="+50">
</datalist>

input { height: 75px; width: 49px; background: #D5CCBB; color: black; }

This specification does not mandate a particular interface. The UA could have used a rotary control, a combo box, a voice-driven text box, or any other widget or interface while still being compliant with this specification.

2.13. The output element

The output element acts very much like a span element, except that it is considered to be a form control for the purposes of the DOM. Its namespace (in XML) is the same as for the other form control elements, http://www.w3.org/1999/xhtml.

The output element may have any of the common attributes, the form and name attributes, the for attribute (defined below), and the onchange, onforminput and onformchange attributes.

Its current value is given by its contents, which may be any inline content (like the span element).

The current value can be set and retrieved dynamically using the mutable value DOM attribute of type DOMString. This attribute is defined to be identical to the DOM3 Core textContent attribute. [DOM3CORE]

The initial value of the output control is stored in a mutable defaultValue DOM attribute of type DOMString. See [HTML4] section 17.2 for the definiton of the term "initial value". (In brief, it is the value used when the form is reset.)

The defaultValue DOM a