4.10.20.2 Constraint validation

When the user agent is required to statically validate the constraints of form element form, it must run the following steps, which return either a positive result (all the controls in the form are valid) or a negative result (there are invalid controls) along with a (possibly empty) list of elements that are invalid and for which no script has claimed responsibility:

  1. Let controls be a list of all the submittable elements whose form owner is form, in tree order.

  2. Let invalid controls be an initially empty list of elements.

  3. For each element field in controls, in tree order, run the following substeps:

    1. If field is not a candidate for constraint validation, then move on to the next element.

    2. Otherwise, if field satisfies its constraints, then move on to the next element.

    3. Otherwise, add field to invalid controls.

  4. If invalid controls is empty, then return a positive result and abort these steps.

  5. Let unhandled invalid controls be an initially empty list of elements.

  6. For each element field in invalid controls, if any, in tree order, run the following substeps:

    1. Fire a simple event named invalid that is cancelable at field.

    2. If the event was not canceled, then add field to unhandled invalid controls.

  7. Return a negative result with the list of elements in the unhandled invalid controls list.

If a user agent is to interactively validate the constraints of form element form, then the user agent must run the following steps:

  1. Statically validate the constraints of form, and let unhandled invalid controls be the list of elements returned if the result was negative.

  2. If the result was positive, then return that result and abort these steps.

  3. Report the problems with the constraints of at least one of the elements given in unhandled invalid controls to the user. User agents may focus one of those elements in the process, by running the focusing steps for that element, and may change the scrolling position of the document, or perform some other action that brings the element to the user's attention. User agents may report more than one constraint violation. User agents may coalesce related constraint violation reports if appropriate (e.g. if multiple radio buttons in a group are marked as required, only one error need be reported). If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error.

  4. Return a negative result.

4.10.20.3 The constraint validation API
element . willValidate

Returns true if the element will be validated when the form is submitted; false otherwise.

element . setCustomValidity(message)

Sets a custom error, so that the element would fail to validate. The given message is the message to be shown to the user when reporting the problem to the user.

If the argument is the empty string, clears the custom error.

element . validity . valueMissing

Returns true if the element has no value but is a required field; false otherwise.

element . validity . typeMismatch

Returns true if the element's value is not in the correct syntax; false otherwise.

element . validity . patternMismatch

Returns true if the element's value doesn't match the provided pattern; false otherwise.

element . validity . tooLong

Returns true if the element's value is longer than the provided maximum length; false otherwise.

element . validity . rangeUnderflow

Returns true if the element's value is lower than the provided minimum; false otherwise.

element . validity . rangeOverflow

Returns true if the element's value is higher than the provided maximum; false otherwise.

element . validity . stepMismatch

Returns true if the element's value doesn't fit the rules given by the step attribute; false otherwise.

element . validity . customError

Returns true if the element has a custom error; false otherwise.

element . validity . valid

Returns true if the element's value has no validity problems; false otherwise.

valid = element . checkValidity()

Returns true if the element's value has no validity problems; false otherwise. Fires an invalid event at the element in the latter case.

element . validationMessage

Returns the error message that would be shown to the user if the element was to be checked for validity.

The willValidate attribute must return true if an element is a candidate for constraint validation, and false otherwise (i.e. false if any conditions are barring it from constraint validation).

The setCustomValidity(message), when invoked, must set the custom validity error message to the value of the given message argument.

In the following example, a script checks the value of a form control each time it is edited, and whenever it is not a valid value, uses the setCustomValidity() method to set an appropriate message.

<label>Feeling: <input name=f type="text" oninput="check(this)"></label>
<script>
 function check(input) {
   if (input.value == "good" ||
       input.value == "fine" ||
       input.value == "tired") {
     input.setCustomValidity('"' + input.value + '" is not a feeling.');
   } else {
     // input is fine -- reset the error message
     input.setCustomValidity('');
   }
 }
</script>

The validity attribute must return a ValidityState object that represents the validity states of the element. This object is live, and the same object must be returned each time the element's validity attribute is retrieved.

interface ValidityState {
  readonly attribute boolean valueMissing;
  readonly attribute boolean typeMismatch;
  readonly attribute boolean patternMismatch;
  readonly attribute boolean tooLong;
  readonly attribute boolean rangeUnderflow;
  readonly attribute boolean rangeOverflow;
  readonly attribute boolean stepMismatch;
  readonly attribute boolean customError;
  readonly attribute boolean valid;
};

A ValidityState object has the following attributes. On getting, they must return true if the corresponding condition given in the following list is true, and false otherwise.

valueMissing

The control is suffering from being missing.

typeMismatch

The control is suffering from a type mismatch.

patternMismatch

The control is suffering from a pattern mismatch.

tooLong

The control is suffering from being too long.

rangeUnderflow

The control is suffering from an underflow.

rangeOverflow

The control is suffering from an overflow.

stepMismatch

The control is suffering from a step mismatch.

customError

The control is suffering from a custom error.

valid

None of the other conditions are true.

When the checkValidity() method is invoked, if the element is a candidate for constraint validation and does not satisfy its constraints, the user agent must fire a simple event named invalid that is cancelable (but in this case has no default action) at the element and return false. Otherwise, it must only return true without doing anything else.

The validationMessage attribute must return the empty string if the element is not a candidate for constraint validation or if it is one but it satisfies its constraints; otherwise, it must return a suitably localized message that the user agent would show the user if this were the only form control with a validity constraint problem. If the element is a candidate for constraint validation and is suffering from a custom error, then the custom validity error message should be present in the return value.

4.10.20.4 Security

Servers should not rely on client-side validation. Client-side validation can be intentionally bypassed by hostile users, and unintentionally bypassed by users of older user agents or automated tools that do not implement these features. The constraint validation features are only intended to improve the user experience, not to provide any kind of security mechanism.

4.10.21 Form submission

4.10.21.1 Introduction

This section is non-normative.

When forms are submitted, the data in the form is converted into the form specified by the enctype, and then sent to the destination specified by the action using the given method.

For example, take the following form:

<form action="/find.cgi" method=get>
 <input type=text name=t>
 <input type=search name=q>
 <input type=submit>
</form>

If the user types in "cats" in the first field and "fur" in the second, and then hits the submit button, then the user agent will load /find.cgi?t=cats&q=fur.

On the other hand, consider this form:

<form action="/find.cgi" method=post enctype="multipart/form-data">
 <input type=text name=t>
 <input type=search name=q>
 <input type=submit>
</form>

Given the same user input, the result on submission is quite different: the user agent instead does an HTTP POST to the given URL, with as the entity body something like the following text:

------kYFrd4jNJEgCervE
Content-Disposition: form-data; name="t"

cats
------kYFrd4jNJEgCervE
Content-Disposition: form-data; name="q"

fur
------kYFrd4jNJEgCervE--
4.10.21.2 Implicit submission

User agents may establish a button in each form as being the form's default button. This should be the first submit button in tree order whose form owner is that form element, but user agents 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 doing so must cause the form's default button's activation behavior, if any, to be run.

Consequently, if the default button is disabled, the form is not submitted when such an implicit submission mechanism is used. (A button has no activation behavior when disabled.)

If the form has no submit button, then the implicit submission mechanism must just submit the form element from the form element itself.

4.10.21.3 Form submission algorithm

When a form form is submitted from an element submitter (typically a button), optionally with a scripted-submit flag set, the user agent must run the following steps:

  1. If form is in a Document that has no associated browsing context or whose browsing context had its sandboxed forms browsing context flag set when the Document was created, then abort these steps without doing anything.

  2. If form is already being submitted (i.e. the form was submitted again while processing the events fired from the next two steps, probably from a script redundantly calling the submit() method on form), then abort these steps. This doesn't affect the earlier instance of this algorithm.

  3. If the scripted-submit flag is not set, and the submitter element's no-validate state is false, then interactively validate the constraints of form and examine the result: if the result is negative (the constraint validation concluded that there were invalid fields and probably informed the user of this) then abort these steps.

  4. If the scripted-submit flag is not set, then fire a simple event that is cancelable named submit, at form. If the event's default action is prevented (i.e. if the event is canceled) then abort these steps. Otherwise, continue (effectively the default action is to perform the submission).

  5. Let controls be a list of all the submittable elements whose form owner is form, in tree order.

  6. Let the form data set be a list of name-value-type tuples, initially empty.

  7. Constructing the form data set. For each element field in controls, in tree order, run the following substeps:

    1. If any of the following conditions are met, then skip these substeps for this element:

      • The field element has a datalist element ancestor.
      • The field element is disabled.
      • The field element is a button but it is not submitter.
      • The field element is an input element whose type attribute is in the Checkbox state and whose checkedness is false.
      • The field element is an input element whose type attribute is in the Radio Button state and whose checkedness is false.
      • The field element is an input element whose type attribute is in the File Upload state but the control does not have any files selected.
      • The field element is an object element that is not using a plugin.

      Otherwise, process field as follows:

    2. Let type be the value of the type IDL attribute of field.

    3. If the field element is an input element whose type attribute is in the Image Button state, then run these further nested substeps:

      1. If the field element has an name attribute specified and value is not the empty string, let name be that value followed by a single U+002E FULL STOP character (.). Otherwise, let name be the empty string.

      2. Let namex be the string consisting of the concatenation of name and a single U+0078 LATIN SMALL LETTER X character (x).

      3. Let namey be the string consisting of the concatenation of name and a single U+0079 LATIN SMALL LETTER Y character (y).

      4. The field element is submitter, and before this algorithm was invoked the user indicated a coordinate. Let x be the x-component of the coordinate selected by the user, and let y be the y-component of the coordinate selected by the user.

      5. Append an entry in the form data set with the name namex, the value x, and the type type.

      6. Append an entry in the form data set with the name namey and the value y, and the type type.

      7. Skip the remaining substeps for this element: if there are any more elements in controls, return to the top of the constructing the form data set step, otherwise, jump to the next step in the overall form submission algorithm.

    4. If the field element does not have a name attribute specified, or its name attribute's value is the empty string, skip these substeps for this element: if there are any more elements in controls, return to the top of the constructing the form data set step, otherwise, jump to the next step in the overall form submission algorithm.

    5. Let name be the value of the field element's name attribute.

    6. If the field element is a select element, then for each option element in the select element whose selectedness is true, append an entry in the form data set with the name as the name, the value of the option element as the value, and type as the type.

    7. Otherwise, if the field element is an input element whose type attribute is in the Checkbox state or the Radio Button state, then run these further nested substeps:

      1. If the field element has a value attribute specified, then let value be the value of that attribute; otherwise, let value be the string "on".

      2. Append an entry in the form data set with name as the name, value as the value, and type as the type.

    8. Otherwise, if the field element is an input element whose type attribute is in the File Upload state, then for each file selected in the input element, append an entry in the form data set with the name as the name, the file (consisting of the name, the type, and the body) as the value, and type as the type.

    9. Otherwise, if the field element is an object element: try to obtain a form submission value from the plugin, and if that is successful, append an entry in the form data set with name as the name, the returned form submission value as the value, and the string "object" as the type.

    10. Otherwise, append an entry in the form data set with name as the name, the value of the field element as the value, and type as the type.

  8. Let action be the submitter element's action.

  9. If action is the empty string, let action be the document's address.

    This step is a willful violation of RFC 3986, which would require base URL processing here. This violation is motivated by a desire for compatibility with legacy content. [RFC3986]

  10. Resolve the URL action, relative to the submitter element. If this fails, abort these steps. Otherwise, let action be the resulting absolute URL.

  11. Let scheme be the <scheme> of the resulting absolute URL.

  12. Let enctype be the submitter element's enctype.

  13. Let method be the submitter element's method.

  14. Let target be the submitter element's target.

  15. Select the appropriate row in the table below based on the value of scheme as given by the first cell of each row. Then, select the appropriate cell on that row based on the value of method as given in the first cell of each column. Then, jump to the steps named in that cell and defined below the table.

    GET POST PUT DELETE
    http Mutate action Submit as entity body Submit as entity body Delete action
    https Mutate action Submit as entity body Submit as entity body Delete action
    ftp Get action Get action Get action Get action
    javascript Get action Get action Get action Get action
    data Get action Post to data: Put to data: Get action
    mailto Mail with headers Mail as body Mail with headers Mail with headers

    If scheme is not one of those listed in this table, then the behavior is not defined by this specification. User agents should, in the absence of another specification defining this, act in a manner analogous to that defined in this specification for similar schemes.

    The behaviors are as follows:

    Mutate action

    Let query be the result of encoding the form data set using the application/x-www-form-urlencoded encoding algorithm, interpreted as a US-ASCII string.

    Let destination be a new URL that is equal to the action except that its <query> component is replaced by query (adding a U+003F QUESTION MARK character (?) if appropriate).

    Let target browsing context be the form submission target browsing context.

    Navigate target browsing context to destination. If target browsing context was newly created for this purpose by the steps above, then it must be navigated with replacement enabled.

    Submit as entity body

    Let entity body be the result of encoding the form data set using the appropriate form encoding algorithm.

    Let target browsing context be the form submission target browsing context.

    Let MIME type be determined as follows:

    If enctype is application/x-www-form-urlencoded
    Let MIME type be "application/x-www-form-urlencoded".
    If enctype is multipart/form-data
    Let MIME type be "multipart/form-data".
    If enctype is text/plain
    Let MIME type be "text/plain".

    If method is anything but GET or POST, and the origin of action is not the same origin as that of the form element's Document, then abort these steps.

    Otherwise, navigate target browsing context to action using the HTTP method given by method and with entity body as the entity body, of type MIME type. If target browsing context was newly created for this purpose by the steps above, then it must be navigated with replacement enabled.

    Delete action

    Let target browsing context be the form submission target browsing context.

    If the origin of action is not the same origin as that of the form element's Document, then abort these steps.

    Otherwise, navigate target browsing context to action using the DELETE method. If target browsing context was newly created for this purpose by the steps above, then it must be navigated with replacement enabled.

    Get action

    Let target browsing context be the form submission target browsing context.

    Navigate target browsing context to action. If target browsing context was newly created for this purpose by the steps above, then it must be navigated with replacement enabled.

    Post to data:

    Let data be the result of encoding the form data set using the appropriate form encoding algorithm.

    If action contains the string "%%%%" (four U+0025 PERCENT SIGN characters), then %-escape all bytes in data that, if interpreted as US-ASCII, do not match the unreserved production in the URI Generic Syntax, and then, treating the result as a US-ASCII string, further %-escape all the U+0025 PERCENT SIGN characters in the resulting string and replace the first occurrence of "%%%%" in action with the resulting double-escaped string. [RFC3986]

    Otherwise, if action contains the string "%%" (two U+0025 PERCENT SIGN characters in a row, but not four), then %-escape all characters in data that, if interpreted as US-ASCII, do not match the unreserved production in the URI Generic Syntax, and then, treating the result as a US-ASCII string, replace the first occurrence of "%%" in action with the resulting escaped string. [RFC3986]

    Let target browsing context be the form submission target browsing context.

    Navigate target browsing context to the potentially modified action. If target browsing context was newly created for this purpose by the steps above, then it must be navigated with replacement enabled.

    Put to data:

    Let data be the result of encoding the form data set using the appropriate form encoding algorithm.

    Let MIME type be determined as follows:

    If enctype is application/x-www-form-urlencoded
    Let MIME type be "application/x-www-form-urlencoded".
    If enctype is multipart/form-data
    Let MIME type be "multipart/form-data".
    If enctype is text/plain
    Let MIME type be "text/plain".

    Let destination be the result of concatenating the following:

    1. The string "data:".
    2. The value of MIME type.
    3. The string ";base64,".
    4. A base-64 encoded representation of data. [RFC2045]

    Let target browsing context be the form submission target browsing context.

    Navigate target browsing context to destination. If target browsing context was newly created for this purpose by the steps above, then it must be navigated with replacement enabled.

    Mail with headers

    Let headers be the resulting encoding the form data set using the application/x-www-form-urlencoded encoding algorithm, interpreted as a US-ASCII string.

    Replace occurrences of U+002B PLUS SIGN characters (+) in headers with the string "%20".

    Let destination consist of all the characters from the first character in action to the character immediately before the first U+003F QUESTION MARK character (?), if any, or the end of the string if there are none.

    Append a single U+003F QUESTION MARK character (?) to destination.

    Append headers to destination.

    Let target browsing context be the form submission target browsing context.

    Navigate target browsing context to destination. If target browsing context was newly created for this purpose by the steps above, then it must be navigated with replacement enabled.

    Mail as body

    Let body be the resulting encoding the form data set using the appropriate form encoding algorithm and then %-escaping all the bytes in the resulting byte string that, when interpreted as US-ASCII, do not match the unreserved production in the URI Generic Syntax. [RFC3986]

    Let destination have the same value as action.

    If destination does not contain a U+003F QUESTION MARK character (?), append a single U+003F QUESTION MARK character (?) to destination. Otherwise, append a single U+0026 AMPERSAND character (&).

    Append the string "body=" to destination.

    Append body, interpreted as a US-ASCII string, to destination.

    Let target browsing context be the form submission target browsing context.

    Navigate target browsing context to destination. If target browsing context was newly created for this purpose by the steps above, then it must be navigated with replacement enabled.

    The form submission target browsing context is obtained, when needed by the behaviors described above, as follows: If the user indicated a specific browsing context to use when submitting the form, then that is the target browsing context. Otherwise, apply the rules for choosing a browsing context given a browsing context name using target as the name and the browsing context of form as the context in which the algorithm is executed; the resulting browsing context is the target browsing context.

    The appropriate form encoding algorithm is determined as follows:

    If enctype is application/x-www-form-urlencoded
    Use the application/x-www-form-urlencoded encoding algorithm.
    If enctype is multipart/form-data
    Use the multipart/form-data encoding algorithm.
    If enctype is text/plain
    Use the text/plain encoding algorithm.
4.10.21.4 URL-encoded form data

The application/x-www-form-urlencoded encoding algorithm is as follows:

  1. Let result be the empty string.

  2. If the form element has an accept-charset attribute, then, taking into account the characters found in the form data set's names and values, and the character encodings supported by the user agent, select a character encoding from the list given in the form's accept-charset attribute that is an ASCII-compatible character encoding. If none of the encodings are supported, then let the selected character encoding be UTF-8.

    Otherwise, if the document's character encoding is an ASCII-compatible character encoding, then that is the selected character encoding.

    Otherwise, let the selected character encoding be UTF-8.

  3. Let charset be the preferred MIME name of the selected character encoding.

  4. For each entry in the form data set, perform these substeps:

    1. If the entry's name is "_charset_" and its type is "hidden", replace its value with charset.

    2. If the entry's type is "file", replace its value with the file's filename only.

    3. For each character in the entry's name and value that cannot be expressed using the selected character encoding, replace the character by a string consisting of a U+0026 AMPERSAND character (&), a U+0023 NUMBER SIGN character (#), one or more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) representing the Unicode code point of the character in base ten, and finally a U+003B SEMICOLON character (;).

    4. For each character in the entry's name and value, apply the following subsubsteps:

      1. If the character isn't in the range U+0020, U+002A, U+002D, U+002E, U+0030 to U+0039, U+0041 to U+005A, U+005F, U+0061 to U+007A then replace the character with a string formed as follows: Start with the empty string, and then, taking each byte of the character when expressed in the selected character encoding in turn, append to the string a U+0025 PERCENT SIGN character (%) followed by two characters in the ranges U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) and U+0041 LATIN CAPITAL LETTER A to U+0046 LATIN CAPITAL LETTER F representing the hexadecimal value of the byte (zero-padded if necessary).

      2. If the character is a U+0020 SPACE character, replace it with a single U+002B PLUS SIGN character (+).

    5. If the entry's name is "isindex", its type is "text", and this is the first entry in the form data set, then append the value to result and skip the rest of the substeps for this entry, moving on to the next entry, if any, or the next step in the overall algorithm otherwise.

    6. If this is not the first entry, append a single U+0026 AMPERSAND character (&) to result.

    7. Append the entry's name to result.

    8. Append a single U+003D EQUALS SIGN character (=) to result.

    9. Append the entry's value to result.

  5. Encode result as US-ASCII and return the resulting byte stream.

4.10.21.5 Multipart form data

The multipart/form-data encoding algorithm is to encode the form data set using the rules described by RFC2388, Returning Values from Forms: multipart/form-data, and return the resulting byte stream. [RFC2388]

Each entry in the form data set is a field, the name of the entry is the field name and the value of the entry is the field value.

The order of parts must be the same as the order of fields in the form data set. Multiple entries with the same name must be treated as distinct fields.

4.10.21.6 Plain text form data

The text/plain encoding algorithm is as follows:

  1. Let result be the empty string.

  2. If the form element has an accept-charset attribute, then, taking into account the characters found in the form data set's names and values, and the character encodings supported by the user agent, select a character encoding from the list given in the form's accept-charset attribute. If none of the encodings are supported, then let the selected character encoding be UTF-8.

    Otherwise, the selected character encoding is the document's character encoding.

  3. Let charset be the preferred MIME name of the selected character encoding.

  4. If the entry's name is "_charset_" and its type is "hidden", replace its value with charset.

  5. If the entry's type is "file", replace its value with the file's filename only.

  6. For each entry in the form data set, perform these substeps:

    1. Append the entry's name to result.

    2. Append a single U+003D EQUALS SIGN character (=) to result.

    3. Append the entry's value to result.

    4. Append a U+000D CARRIAGE RETURN (CR) U+000A LINE FEED (LF) character pair to result.

  7. Encode result using the selected character encoding and return the resulting byte stream.

4.10.22 Resetting a form

When a form form is reset, the user agent must fire a simple event named reset, that is cancelable, at form, and then, if that event is not canceled, must invoke the reset algorithm of each resettable elements whose form owner is form, and broadcast formchange events from form.

Each resettable element defines its own reset algorithm. Changes made to form controls as part of these algorithms do not count as changes caused by the user (and thus, e.g., do not cause input events to fire).

4.10.23 Event dispatch

When the user agent is to broadcast forminput events or broadcast formchange events from a form element form, it must run the following steps:

  1. Let controls be a list of all the resettable elements whose form owner is form.

  2. If the user agent was to broadcast forminput events, let event name be forminput. Otherwise the user agent was to broadcast formchange events; let event name be formchange.
  3. For each element in controls, in tree order, fire a simple event named event name at the element.

4.11 Interactive elements

4.11.1 The details element

Categories
Flow content.
Sectioning root.
Interactive content.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
One summary element followed by flow content.
Content attributes:
Global attributes
open
DOM interface:
interface HTMLDetailsElement : HTMLElement {
           attribute boolean open;
};

The details element represents a disclosure widget from which the user can obtain additional information or controls.

The details element is not appropriate for footnotes. Please see the section on footnotes for details on how to mark up footnotes.

The first summary element child of the element, if any, represents the summary or legend of the details. If there is no child summary element, the user agent should provide its own legend (e.g. "Details").

The open content attribute is a boolean attribute. If present, it indicates that the details are to be shown to the user. If the attribute is absent, the details are not to be shown.

If the attribute is removed, then the details should be hidden. If the attribute is added, the details should be shown.

The user agent should allow the user to request that the details be shown or hidden. To honor a request for the details to be shown, the user agent must set the open attribute on the element to the value open. To honor a request for the details to be hidden, the user agent must remove the open attribute from the element.

The open attribute must reflect the open content attribute.

The following example shows the details element being used to hide technical details in a progress report.

<section class="progress window">
 <h1>Copying "Really Achieving Your Childhood Dreams"</h1>
 <details>
  <summary>Copying... <progress max="375505392" value="97543282"></progress> 25%</summary>
  <dl>
   <dt>Transfer rate:</dt> <dd>452KB/s</dd>
   <dt>Local filename:</dt> <dd>/home/rpausch/raycd.m4v</dd>
   <dt>Remote filename:</dt> <dd>/var/www/lectures/raycd.m4v</dd>
   <dt>Duration:</dt> <dd>01:16:27</dd>
   <dt>Color profile:</dt> <dd>SD (6-1-6)</dd>
   <dt>Dimensions:</dt> <dd>320×240</dd>
  </dl>
 </details>
</section>

The following shows how a details element can be used to hide some controls by default:

<details>
 <summary>Name & Extension:</summary>
 <p><input type=text name=fn value="Pillar Magazine.pdf">
 <p><label><input type=checkbox name=ext checked> Hide extension</label>
</details>

One could use this in conjuction with other details in a list to allow the user to collapse a set of fields down to a small set of headings, with the ability to open each one.

In these examples, the summary really just summarises what the controls can change, and not the actual values, which is less than ideal.

4.11.2 The summary element

Categories
None.
Contexts in which this element may be used:
As the first child of a details element.
Content model:
Phrasing content.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

The summary element represents a summary, caption, or legend for the rest of the contents of the summary element's parent details element, if any.

4.11.3 The command element

Categories
Metadata content.
Flow content.
Phrasing content.
Contexts in which this element may be used:
Where metadata content is expected.
Where phrasing content is expected.
Content model:
Empty.
Content attributes:
Global attributes
type
label
icon
disabled
checked
radiogroup
Also, the title attribute has special semantics on this element.
DOM interface:
interface HTMLCommandElement : HTMLElement {
           attribute DOMString type;
           attribute DOMString label;
           attribute DOMString icon;
           attribute boolean disabled;
           attribute boolean checked;
           attribute DOMString radiogroup;
};

The command element represents a command that the user can invoke.

The type attribute indicates the kind of command: either a normal command with an associated action, or a state or option that can be toggled, or a selection of one item from a list of items.

The attribute is an enumerated attribute with three keywords and states. The "command" keyword maps to the Command state, the "checkbox" keyword maps to the Checkbox state, and the "radio" keyword maps to the Radio state. The missing value default is the Command state.

The Command state

The element represents a normal command with an associated action.

The Checkbox state

The element represents a state or option that can be toggled.

The Radio state

The element represents a selection of one item from a list of items.

The label attribute gives the name of the command, as shown to the user. The label attribute must be specified and must have a value that is not the empty string.

The title attribute gives a hint describing the command, which might be shown to the user to help him.

The icon attribute gives a picture that represents the command. If the attribute is specified, the attribute's value must contain a valid non-empty URL. To obtain the absolute URL of the icon when the attribute's value is not the empty string, the attribute's value must be resolved relative to the element. When the attribute is absent, or its value is the empty string, or resolving its value fails, there is no icon.

The disabled attribute is a boolean attribute that, if present, indicates that the command is not available in the current state.

The distinction between disabled and hidden is subtle. A command would be disabled if, in the same context, it could be enabled if only certain aspects of the situation were changed. A command would be marked as hidden if, in that situation, the command will never be enabled. For example, in the context menu for a water faucet, the command "open" might be disabled if the faucet is already open, but the command "eat" would be marked hidden since the faucet could never be eaten.

The checked attribute is a boolean attribute that, if present, indicates that the command is selected. The attribute must be omitted unless the type attribute is in either the Checkbox state or the Radio state.

The radiogroup attribute gives the name of the group of commands that will be toggled when the command itself is toggled, for commands whose type attribute has the value "radio". The scope of the name is the child list of the parent element. The attribute must be omitted unless the type attribute is in the Radio state.

The type, label, icon, disabled, checked, and radiogroup IDL attributes must reflect the respective content attributes of the same name.

The element's activation behavior depends on the value of the type attribute of the element, as follows:

If the type attribute is in the Checkbox state

If the element has a checked attribute, the UA must remove that attribute. Otherwise, the UA must add a checked attribute, with the literal value checked. The UA must then fire a click event at the element.

If the type attribute is in the Radio state

If the element has a parent, then the UA must walk the list of child nodes of that parent element, and for each node that is a command element, if that element has a radiogroup attribute whose value exactly matches the current element's (treating missing radiogroup attributes as if they were the empty string), and has a checked attribute, must remove that attribute.

Then, the element's checked attribute attribute must be set to the literal value checked and the user agent must fire a click event at the element.

Otherwise

The element has no activation behavior.

Firing a synthetic click event at the element does not cause any of the actions described above to happen.

command elements are not rendered unless they form part of a menu.

Here is an example of a toolbar with three buttons that let the user toggle between left, center, and right alignment. One could imagine such a toolbar as part of a text editor. The toolbar also has a separator followed by another button labeled "Publish", though that button is disabled.

<menu type="toolbar">
 <command type="radio" radiogroup="alignment" checked="checked"
          label="Left" icon="icons/alL.png" onclick="setAlign('left')">
 <command type="radio" radiogroup="alignment"
          label="Center" icon="icons/alC.png" onclick="setAlign('center')">
 <command type="radio" radiogroup="alignment"
          label="Right" icon="icons/alR.png" onclick="setAlign('right')">
 <hr>
 <command type="command" disabled
          label="Publish" icon="icons/pub.png" onclick="publish()">
</menu>
Categories
Flow content.
If the element's type attribute is in the toolbar state: Interactive content.
Contexts in which this element may be used:
Where flow content is expected.
Content model:
Either: Zero or more li elements.
Or: Flow content.
Content attributes:
Global attributes
type
label
DOM interface:
interface HTMLMenuElement : HTMLElement {
           attribute DOMString type;
           attribute DOMString label;
};

The menu element represents a list of commands.

The type attribute is an enumerated attribute indicating the kind of menu being declared. The attribute has three states. The context keyword maps to the context menu state, in which the element is declaring a context menu. The toolbar keyword maps to the toolbar state, in which the element is declaring a toolbar. The attribute may also be omitted. The missing value default is the list state, which indicates that the element is merely a list of commands that is neither declaring a context menu nor defining a toolbar.

If a menu element's type attribute is in the context menu state, then the element represents the commands of a context menu, and the user can only interact with the commands if that context menu is activated.

If a menu element's type attribute is in the toolbar state, then the element represents a list of active commands that the user can immediately interact with.

If a menu element's type attribute is in the list state, then the element either represents an unordered list of items (each represented by an li element), each of which represents a command that the user can perform or activate, or, if the element has no li element children, flow content describing available commands.

The label attribute gives the label of the menu. It is used by user agents to display nested menus in the UI. For example, a context menu containing another menu would use the nested menu's label attribute for the submenu's menu label.

The type and label IDL attributes must reflect the respective content attributes of the same name.

This section is non-normative.

The menu element is used to define context menus and toolbars.

For example, the following represents a toolbar with three menu buttons on it, each of which has a dropdown menu with a series of options:

<menu type="toolbar">
 <li>
  <menu label="File">
   <button type="button" onclick="fnew()">New...</button>
   <button type="button" onclick="fopen()">Open...</button>
   <button type="button" onclick="fsave()">Save</button>
   <button type="button" onclick="fsaveas()">Save as...</button>
  </menu>
 </li>
 <li>
  <menu label="Edit">
   <button type="button" onclick="ecopy()">Copy</button>
   <button type="button" onclick="ecut()">Cut</button>
   <button type="button" onclick="epaste()">Paste</button>
  </menu>
 </li>
 <li>
  <menu label="Help">
   <li><a href="help.html">Help</a></li>
   <li><a href="about.html">About</a></li>
  </menu>
 </li>
</menu>

In a supporting user agent, this might look like this:

A toolbar with three buttons, labeled 'File', 'Edit', and 'Help'; where if you select the 'Edit' button you get a drop-down menu with three more options, 'Copy', 'Cut', and 'Paste'.

In a legacy user agent, the above would look like a bulleted list with three items, the first of which has four buttons, the second of which has three, and the third of which has two nested bullet points with two items consisting of links.


The following implements a similar toolbar, with a single button whose values, when selected, redirect the user to Web sites.

<form action="redirect.cgi">
 <menu type="toolbar">
  <label for="goto">Go to...</label>
  <menu label="Go">
   <select id="goto">
    <option value="" selected="selected"> Select site: </option>
    <option value="http://www.apple.com/"> Apple </option>
    <option value="http://www.mozilla.org/"> Mozilla </option>
    <option value="http://www.opera.com/"> Opera </option>
   </select>
   <span><input type="submit" value="Go"></span>
  </menu>
 </menu>
</form>

The behavior in supporting user agents is similar to the example above, but here the legacy behavior consists of a single select element with a submit button. The submit button doesn't appear in the toolbar, because it is not a direct child of the menu element or of its li children.

4.11.4.2 Building menus and toolbars

A menu (or toolbar) consists of a list of zero or more of the following components:

The list corresponding to a particular menu element is built by iterating over its child nodes. For each child node in tree order, the required behavior depends on what the node is, as follows:

An element that defines a command
Append the command to the menu, respecting its facets.
An hr element
An option element that has a value attribute set to the empty string, and has a disabled attribute, and whose textContent consists of a string of one or more hyphens (U+002D HYPHEN-MINUS)
Append a separator to the menu.
An li element
A label element
Iterate over the children of the element.
A menu element with no label attribute
A select element
Append a separator to the menu, then iterate over the children of the menu or select element, then append another separator.
A menu element with a label attribute
An optgroup element with a label attribute
Append a submenu to the menu, using the value of the element's label attribute as the label of the menu. The submenu must be constructed by taking the element and creating a new menu for it using the complete process described in this section.
Any other node
Ignore the node.

Once all the nodes have been processed as described above, the user agent must the post-process the menu as follows:

  1. Except for separators, any menu item with no label, or whose label is the empty string, must be removed.
  2. Any sequence of two or more separators in a row must be collapsed to a single separator.
  3. Any separator at the start or end of the menu must be removed.
4.11.4.3 Context menus

The contextmenu attribute gives the element's context menu. The value must be the ID of a menu element in the DOM. If the node that would be obtained by the invoking the getElementById() method using the attribute's value as the only argument is null or not a menu element, then the element has no assigned context menu. Otherwise, the element's assigned context menu is the element so identified.

When an element's context menu is requested (e.g. by the user right-clicking the element, or pressing a context menu key), the UA must fire a simple event named contextmenu that bubbles and is cancelable at the element for which the menu was requested.

Typically, therefore, the firing of the contextmenu event will be the default action of a mouseup or keyup event. The exact sequence of events is UA-dependent, as it will vary based on platform conventions.

The default action of the contextmenu event depends on whether the element or one of its ancestors has a context menu assigned (using the contextmenu attribute) or not. If there is no context menu assigned, the default action must be for the user agent to show its default context menu, if it has one.

If the element or one of its ancestors does have a context menu assigned, then the user agent must fire a simple event named show at the menu element of the context menu of the nearest ancestor (including the element itself) with one assigned.

The default action of this event is that the user agent must show a context menu built from the menu element.

The user agent may also provide access to its default context menu, if any, with the context menu shown. For example, it could merge the menu items from the two menus together, or provide the page's context menu as a submenu of the default menu.

If the user dismisses the menu without making a selection, nothing in particular happens.

If the user selects a menu item that represents a command, then the UA must invoke that command's Action.

Context menus must not, while being shown, reflect changes in the DOM; they are constructed as the default action of the show event and must remain as constructed until dismissed.

User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus. For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu.

The contextMenu attribute must reflect the contextmenu content attribute.

Here is an example of a context menu for an input control:

<form name="npc">
 <label>Character name: <input name=char type=text contextmenu=namemenu required></label>
 <menu type=context id=namemenu>
  <command label="Pick random name" onclick="document.forms.npc.elements.char.value = getRandomName()">
  <command label="Prefill other fields based on name" onclick="prefillFields(document.forms.npc.elements.char.value)">
 </menu>
</form>

This adds to items to the control's context menu, one called "Pick random name", and one called "Prefill other fields based on name". They invoke scripts that are not shown in the example above.

4.11.4.4 Toolbars

When a menu element has a type attribute in the toolbar state, then the user agent must build the menu for that menu element, and use the result in the rendering.

The user agent must reflect changes made to the menu's DOM, by immediately rebuilding the menu.

4.11.5 Commands

A command is the abstraction behind menu items, buttons, and links.

Commands are defined to have the following facets:

Type
The kind of command: "command", meaning it is a normal command; "radio", meaning that triggering the command will, amongst other things, set the Checked State to true (and probably uncheck some other commands); or "checkbox", meaning that triggering the command will, amongst other things, toggle the value of the Checked State.
ID
The name of the command, for referring to the command from the markup or from script. If a command has no ID, it is an anonymous command.
Label
The name of the command as seen by the user.
Hint
A helpful or descriptive string that can be shown to the user.
Icon
An absolute URL identifying a graphical image that represents the action. A command might not have an Icon.
Access Key
A key combination selected by the user agent that triggers the command. A command might not have an Access Key.
Hidden State
Whether the command is hidden or not (basically, whether it should be shown in menus).
Disabled State
Whether the command is relevant and can be triggered or not.
Checked State
Whether the command is checked or not.
Action
The actual effect that triggering the command will have. This could be a scripted event handler, a URL to which to navigate, or a form submission.

These facets are exposed on elements using the command API:

element . commandType

Exposes the Type facet of the command.

element . id

Exposes the ID facet of the command.

element . label

Exposes the Label facet of the command.

element . title

Exposes the Hint facet of the command.

element . icon

Exposes the Icon facet of the command.

element . accessKeyLabel

Exposes the Access Key facet of the command.

element . hidden

Exposes the Hidden State facet of the command.

element . disabled

Exposes the Disabled State facet of the command.

element . checked

Exposes the Checked State facet of the command.

element . click()

Triggers the Action of the command.

The commandType attribute must return a string whose value is either "command", "radio", or "checkbox", depending on whether the Type of the command defined by the element is "command", "radio", or "checkbox" respectively. If the element does not define a command, it must return null.

The label attribute must return the command's Label, or null if the element does not define a command or does not specify a Label. This attribute will be shadowed by the label IDL attribute on various elements.

The icon attribute must return the absolute URL of the command's Icon. If the element does not specify an icon, or if the element does not define a command, then the attribute must return null. This attribute will be shadowed by the icon IDL attribute on command elements.

The disabled attribute must return true if the command's Disabled State is that the command is disabled, and false if the command is not disabled. This attribute is not affected by the command's Hidden State. If the element does not define a command, the attribute must return false. This attribute will be shadowed by the disabled IDL attribute on various elements.

The checked attribute must return true if the command's Checked State is that the command is checked, and false if it is that the command is not checked. If the element does not define a command, the attribute must return false. This attribute will be shadowed by the checked IDL attribute on input and command elements.

The ID facet is exposed by the id IDL attribute, the Hint facet is exposed by the title IDL attribute, the AccessKey facet is exposed by the accessKeyLabel IDL attribute, and the Hidden State facet is exposed by the hidden IDL attribute.


document . commands

Returns an HTMLCollection of the elements in the Document that define commands and have IDs.

The commands attribute of the document's HTMLDocument interface must return an HTMLCollection rooted at the Document node, whose filter matches only elements that define commands and have IDs.


User agents may expose the commands whose Hidden State facet is false (visible), e.g. in the user agent's menu bar. User agents are encouraged to do this especially for commands that have Access Keys, as a way to advertise those keys to the user.

4.11.5.1 Using the a element to define a command

An a element with an href attribute defines a command.

The Type of the command is "command".

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command is the string given by the element's textContent IDL attribute.

The Hint of the command is the value of the title attribute of the element. If the attribute is not present, the Hint is the empty string.

The Icon of the command is the absolute URL obtained from resolving the value of the src attribute of the first img element descendant of the element, relative to that element, if there is such an element and resolving its attribute is successful. Otherwise, there is no Icon for the command.

The AccessKey of the command is the element's assigned access key, if any.

The Hidden State of the command is true (hidden) if the element has a hidden attribute, and false otherwise.

The Disabled State facet of the command is always false. (The command is always enabled.)

The Checked State of the command is always false. (The command is never checked.)

The Action of the command is to fire a click event at the element.

4.11.5.2 Using the button element to define a command

A button element always defines a command.

The Type, ID, Label, Hint, Icon, Access Key, Hidden State, Checked State, and Action facets of the command are determined as for a elements (see the previous section).

The Disabled State of the command mirrors the disabled state of the button.

4.11.5.3 Using the input element to define a command

An input element whose type attribute is in one of the Submit Button, Reset Button, Image Button, Button, Radio Button, or Checkbox states defines a command.

The Type of the command is "radio" if the type attribute is in the Radio Button state, "checkbox" if the type attribute is in the Checkbox state, and "command" otherwise.

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command depends on the Type of the command:

If the Type is "command", then it is the string given by the value attribute, if any, and a UA-dependent, locale-dependent value that the UA uses to label the button itself if the attribute is absent.

Otherwise, the Type is "radio" or "checkbox". If the element is a labeled control, the textContent of the first label element in tree order whose labeled control is the element in question is the Label (in DOM terms, this is the string given by element.labels[0].textContent). Otherwise, the value of the value attribute, if present, is the Label. Otherwise, the Label is the empty string.

The Hint of the command is the value of the title attribute of the input element. If the attribute is not present, the Hint is the empty string.

If the element's type attribute is in the Image Button state, and the element has a src attribute, and that attribute's value can be successfully resolved relative to the element, then the Icon of the command is the absolute URL obtained from resolving that attribute that way. Otherwise, there is no Icon for the command.

The AccessKey of the command is the element's assigned access key, if any.

The Hidden State of the command is true (hidden) if the element has a hidden attribute, and false otherwise.

The Disabled State of the command mirrors the disabled state of the control.

The Checked State of the command is true if the command is of Type "radio" or "checkbox" and the element is checked attribute, and false otherwise.

The Action of the command, if the element has a defined activation behavior, is to run synthetic click activation steps on the element. Otherwise, it is just to fire a click event at the element.

4.11.5.4 Using the option element to define a command

An option element with an ancestor select element and either no value attribute or a value attribute that is not the empty string defines a command.

The Type of the command is "radio" if the option's nearest ancestor select element has no multiple attribute, and "checkbox" if it does.

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command is the value of the option element's label attribute, if there is one, or the value of the option element's textContent IDL attribute if there isn't.

The Hint of the command is the string given by the element's title attribute, if any, and the empty string if the attribute is absent.

There is no Icon for the command.

The AccessKey of the command is the element's assigned access key, if any.

The Hidden State of the command is true (hidden) if the element has a hidden attribute, and false otherwise.

The Disabled State of the command is true (disabled) if the element is disabled or if its nearest ancestor select element is disabled, and false otherwise.

The Checked State of the command is true (checked) if the element's selectedness is true, and false otherwise.

The Action of the command depends on its Type. If the command is of Type "radio" then it must pick the option element. Otherwise, it must toggle the option element.

4.11.5.5 Using the command element to define a command

A command element defines a command.

The Type of the command is "radio" if the command's type attribute is "radio", "checkbox" if the attribute's value is "checkbox", and "command" otherwise.

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command is the value of the element's label attribute, if there is one, or the empty string if it doesn't.

The Hint of the command is the string given by the element's title attribute, if any, and the empty string if the attribute is absent.

The Icon for the command is the absolute URL obtained from resolving the value of the element's icon attribute, relative to the element, if it has such an attribute and resolving it is successful. Otherwise, there is no Icon for the command.

The AccessKey of the command is the element's assigned access key, if any.

The Hidden State of the command is true (hidden) if the element has a hidden attribute, and false otherwise.

The Disabled State of the command is true (disabled) if the element has a disabled attribute, and false otherwise.

The Checked State of the command is true (checked) if the element has a checked attribute, and false otherwise.

The Action of the command, if the element has a defined activation behavior, is to run synthetic click activation steps on the element. Otherwise, it is just to fire a click event at the element.

4.11.5.6 Using the accesskey attribute on a label element to define a command

A label element that has an assigned access key and a labeled control and whose labeled control defines a command, itself defines a command.

The Type of the command is "command".

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command is the string given by the element's textContent IDL attribute.

The Hint of the command is the value of the title attribute of the element.

There is no Icon for the command.

The AccessKey of the command is the element's assigned access key.

The Hidden State, Disabled State, and Action facets of the command are the same as the respective facets of the element's labeled control.

The Checked State of the command is always false. (The command is never checked.)

4.11.5.7 Using the accesskey attribute on a legend element to define a command

A legend element that has an assigned access key and is a child of a fieldset element that has a descendant that is not a descendant of the legend element and is neither a label element nor a legend element but that defines a command, itself defines a command.

The Type of the command is "command".

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command is the string given by the element's textContent IDL attribute.

The Hint of the command is the value of the title attribute of the element.

There is no Icon for the command.

The AccessKey of the command is the element's assigned access key.

The Hidden State, Disabled State, and Action facets of the command are the same as the respective facets of the first element in tree order that is a descendant of the parent of the legend element that defines a command but is not a descendant of the legend element and is neither a label nor a legend element.

The Checked State of the command is always false. (The command is never checked.)

4.11.5.8 Using the accesskey attribute to define a command on other elements

An element that has an assigned access key defines a command.

If one of the other sections that define elements that define commands define that this element defines a command, then that section applies to this element, and this section does not. Otherwise, this section applies to that element.

The Type of the command is "command".

The ID of the command is the value of the id attribute of the element, if the attribute is present and not empty. Otherwise the command is an anonymous command.

The Label of the command depends on the element. If the element is a labeled control, the textContent of the first label element in tree order whose labeled control is the element in question is the Label (in DOM terms, this is the string given by element.labels[0].textContent). Otherwise, the Label is the textContent of the element itself.

The Hint of the command is the value of the title attribute of the element. If the attribute is not present, the Hint is the empty string.

There is no Icon for the command.

The AccessKey of the command is the element's assigned access key.

The Hidden State of the command is true (hidden) if the element has a hidden attribute, and false otherwise.

The Disabled State facet of the command is always false. (The command is always enabled.)

The Checked State of the command is always false. (The command is never checked.)

The Action of the command is to run the following steps:

  1. If the element is focusable, run the focusing steps for the element.
  2. If the element has a defined activation behavior, run synthetic click activation steps on the element.
  3. Otherwise, if the element does not have a defined activation behavior, fire a click event at the element.

4.11.6 The device element

Categories
Flow content.
Phrasing content.
Interactive content.
Contexts in which this element may be used:
Where phrasing content is expected.
Content model:
Empty.
Content attributes:
Global attributes
type
DOM interface:
interface HTMLDeviceElement : HTMLElement {
           attribute DOMString type;
  readonly attribute any data;
};

The device element represents a device selector, to allow the user to give the page access to a device, for example a video camera.

The type attribute allows the author to specify which kind of device the page would like access to. The attribute is an enumerated attribute with the keywords given in the first column of the following table, and their corresponding states given in the cell in second column of the same row.

RS232 is only included below to give an idea of where we could go with this. Should we instead just make this only useful for audiovisual streams? Unless there are compelling reasons, we probably should not be this generic. So far, the reasons aren't that compelling.

Keyword State Device description Examples
media Media Stream of audio and/or video data. A webcam.
fs File system File system. A USB-connected media player.
rs232 RS232 RS232 device. A serial port.

processing model: 'change' event fires once user selects a new device; .data is set to new Stream, LocalFS, or RS232 object as appropriate.

<p>To start chatting, select a video camera: <device type=media onchange="update(this.data)"></p>
<video autoplay></video>
<script>
 function update(stream) {
   document.getElementsByTagName('video')[0].src = stream.URL;
 }
</script>
4.11.6.1 Stream API

The Stream interface is used to represent streams.

interface Stream {
  readonly attribute DOMString URL;
  StreamRecorder record();
};

The URL attribute must return a File URN representing the stream. [FILEAPI]

For audio and video streams, the stream must be in a format supported by the user agent for use in audio and video elements.

This will be pinned down to a specific codec.

When the record() method is invoked, the user agent must return a new StreamRecorder object associated with the stream.

interface StreamRecorder {
  File stop();
};

The stop() method must return a new File object representing the data that was streamed between the creation of the StreamRecorder object and the invocation of the stop() method. [FILEAPI]

For audio and video streams, the file must be in a format supported by the user agent for use in audio and video elements.

This again will be pinned down to a specific codec.

4.11.6.2 Peer-to-peer connections

This section will be moved to a more appropriate location in due course; it is here currently to keep it near the device element to allow reviewers to look at it.

[NoInterfaceObject]
interface AbstractPeer {
  void sendText(in DOMString text);
  attribute Function ontext; // receiving

  void sendBitmap(in HTMLImageElement image);
  attribute Function onbitmap; // receiving

  void sendFile(in File file);
  attribute Function onfile; // receiving

  attribute Stream localStream; // video/audio to send
  readonly attribute Stream remoteStream; // video/audio from remote peer
  attribute Function onstreamchange; // when the remote peer changes whether the video is being sent or not

  attribute Function onconnect;
  attribute Function onerror;
  attribute Function ondisconnect;
};

[Constructor(in DOMString serverConfiguration)]
interface PeerToPeerServer : AbstractPeer {
  void getClientConfiguration(in PeerToPeerConfigurationCallback callback);

  void close(); // disconnects and stops listening
};

[Constructor]
interface PeerToPeerClient : AbstractPeer {
  void addConfiguration(in DOMString configuration);
  void close(); // disconnects
};

[Callback=FunctionOnly, NoInterfaceObject]
interface PeerToPeerConfigurationCallback {
  void handleEvent(in PeerToPeerServer server, in DOMString configuration);
};

...

This relies on some currently hypothetical other standard to define:

Server:

var serverConfig = ...; // configuration string obtained from server
// contains details such as the IP address of a server that can speak some
// protocol to help the client determine its public IP address, route packets
// if necessary, etc.

var local = new PeerToPeerServer(serverConfig);
local.getClientConfiguration(function (configuration) {
  if (configuration != '') {
    ...; // send configuration to other peer using out-of-band mechanism
  } else {
    // we've exhausted our options; wait for connection
  }
});

Client:

var local = new PeerToPeerClient();
function ... (configuration) {
  // called whenever we get configuration information out-of-band
  local.addConfiguration(configuration);
}

Both client and server:

local.onconnect = function (event) {
  // we are connected!
  local.sendText('Hello');
  local.localStream = ...; // send video
  local.onstreamchange = function (event) {
    // receive video
    // (videoElement is some <video> element)
    videoElement.src = local.remoteStream.URL;
  };
};

To prevent network sniffing from allowing a fourth party to establish a connection to the PeerToPeerServer using the information sent out-of-band to the PeerToPeerClient and thus spoofing the client, the configuration information should always be transmitted using an encrypted connection.

The a, area, and link elements can, in certain situations described in the definitions of those elements, represent hyperlinks.

The href attribute on a and area elements must have a value that is a valid URL. This URL is the destination resource of the hyperlink.

The href attribute on a and area elements is not required; when those elements do not have href attributes they do not represent hyperlinks.

The href attribute on the link element is required (and has to be a valid non-empty URL), but whether a link element represents a hyperlink or not depends on the value of the rel attribute of that element.

The target attribute, if present, must be a valid browsing context name or keyword. It gives the name of the browsing context that will be used. User agents use this name when following hyperlinks.

The ping attribute, if present, gives the URLs of the resources that are interested in being notified if the user follows the hyperlink. The value must be a set of space-separated tokens, each of which must be a valid non-empty URL. The value is used by the user agent for hyperlink auditing.

For a and area elements that represent hyperlinks, the relationship between the document containing the hyperlink and the destination resource indicated by the hyperlink is given by the value of the element's rel attribute, which must be a set of space-separated tokens. The allowed values and their meanings are defined below. The rel attribute has no default value. If the attribute is omitted or if none of the values in the attribute are recognized by the user agent, then the document has no particular relationship with the destination resource other than there being a hyperlink between the two.

The media attribute describes for which media the target document was designed. It is purely advisory. The value must be a valid media query. The default, if the media attribute is omitted, is "all".

The hreflang attribute on hyperlink elements, if present, gives the language of the linked resource. It is purely advisory. The value must be a valid BCP 47 language code. [BCP47] User agents must not consider this attribute authoritative — upon fetching the resource, user agents must use only language information associated with the resource to determine its language, not metadata included in the link to the resource.

The type attribute, if present, gives the MIME type of the linked resource. It is purely advisory. The value must be a valid MIME type. User agents must not consider the type attribute authoritative — upon fetching the resource, user agents must not use metadata included in the link to the resource to determine its type.

When a user follows a hyperlink, the user agent must resolve the URL given by the href attribute of that hyperlink, relative to the hyperlink element, and if that is successful, must navigate a browsing context to the resulting absolute URL. In the case of server-side image maps, the URL of the hyperlink must further have its hyperlink suffix appended to it.

If resolving the URL fails, the user agent may report the error to the user in a user-agent-specific manner, may navigate to an error page to report the error, or may ignore the error and do nothing.

If the user indicated a specific browsing context when following the hyperlink, or if the user agent is configured to follow hyperlinks by navigating a particular browsing context, then that must be the browsing context that is navigated.

Otherwise, if the hyperlink element is an a or area element that has a target attribute, then the browsing context that is navigated must be chosen by applying the rules for choosing a browsing context given a browsing context name, using the value of the target attribute as the browsing context name. If these rules result in the creation of a new browsing context, it must be navigated with replacement enabled.

Otherwise, if the hyperlink element is a sidebar hyperlink and the user agent implements a feature that can be considered a secondary browsing context, such a secondary browsing context may be selected as the browsing context to be navigated.

Otherwise, if the hyperlink element is an a or area element with no target attribute, but one of the child nodes of the head element is a base element with a target attribute, then the browsing context that is navigated must be chosen by applying the rules for choosing a browsing context given a browsing context name, using the value of the target attribute of the first such base element as the browsing context name. If these rules result in the creation of a new browsing context, it must be navigated with replacement enabled.

Otherwise, the browsing context that must be navigated is the same browsing context as the one which the hyperlink element itself is in.

The navigation must be done with the browsing context that contains the Document object with which the hyperlink's element in question is associated as the source browsing context.