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:
Let controls be a list of all the submittable elements whose form owner is form, in tree order.
Let invalid controls be an initially empty list of elements.
For each element field in controls, in tree order, run the following substeps:
If field is not a candidate for constraint validation, then move on to the next element.
Otherwise, if field satisfies its constraints, then move on to the next element.
Otherwise, add field to invalid controls.
If invalid controls is empty, then return a positive result and abort these steps.
Let unhandled invalid controls be an initially empty list of elements.
For each element field in invalid controls, if any, in tree order, run the following substeps:
Fire a simple event named invalid that is cancelable at field.
If the event was not canceled, then add field to unhandled invalid controls.
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:
Statically validate the constraints of form, and let unhandled invalid controls be the list of elements returned if the result was negative.
If the result was positive, then return that result and abort these steps.
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.
Return a negative result.
willValidateReturns true if the element will be validated when the form is submitted; false otherwise.
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.
validity . valueMissingReturns true if the element has no value but is a required field; false otherwise.
validity . typeMismatchReturns true if the element's value is not in the correct syntax; false otherwise.
validity . patternMismatchReturns true if the element's value doesn't match the provided pattern; false otherwise.
validity . tooLongReturns true if the element's value is longer than the provided maximum length; false otherwise.
validity . rangeUnderflowReturns true if the element's value is lower than the provided minimum; false otherwise.
validity . rangeOverflowReturns true if the element's value is higher than the provided maximum; false otherwise.
validity . stepMismatchReturns true if the element's value doesn't fit the rules given by the step attribute; false otherwise.
validity . customErrorReturns true if the element has a custom error; false otherwise.
validity . validReturns true if the element's value has no validity problems; false otherwise.
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.
validationMessageReturns 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.
valueMissingThe control is suffering from being missing.
typeMismatchThe control is suffering from a type mismatch.
patternMismatchThe control is suffering from a pattern mismatch.
tooLongThe control is suffering from being too long.
rangeUnderflowThe control is suffering from an underflow.
rangeOverflowThe control is suffering from an overflow.
stepMismatchThe control is suffering from a step mismatch.
customErrorThe control is suffering from a custom error.
validNone 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.
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.
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--
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.
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:
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.
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.
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.
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).
Let controls be a list of all the submittable elements whose form owner is form, in tree order.
Let the form data set be a list of name-value-type tuples, initially empty.
Constructing the form data set. For each element field in controls, in tree order, run the following substeps:
If any of the following conditions are met, then skip these substeps for this element:
datalist element ancestor.input element whose type attribute is in the Checkbox state and
whose checkedness is
false.input element whose type attribute is in the Radio Button state and
whose checkedness is
false.input element whose type attribute is in the File Upload state but
the control does not have any files selected.object element that is not using a
plugin.Otherwise, process field as follows:
Let type be the value of the type IDL attribute of field.
If the field element is an
input element whose type attribute is in the Image Button state,
then run these further nested substeps:
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.
Let namex be the string consisting of the concatenation of name and a single U+0078 LATIN SMALL LETTER X character (x).
Let namey be the string consisting of the concatenation of name and a single U+0079 LATIN SMALL LETTER Y character (y).
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.
Append an entry in the form data set with the name namex, the value x, and the type type.
Append an entry in the form data set with the name namey and the value y, and the type type.
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.
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.
Let name be the value of the field element's name attribute.
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.
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:
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".
Append an entry in the form data set with name as the name, value as the value, and type as the type.
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.
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.
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.
Let action be the submitter element's action.
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]
Resolve the URL action, relative to the submitter element. If this fails, abort these steps. Otherwise, let action be the resulting absolute URL.
Let scheme be the <scheme> of the resulting absolute URL.
Let enctype be the submitter element's enctype.
Let method be the submitter element's method.
Let target be the submitter element's target.
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.
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:
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.
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:
application/x-www-form-urlencodedapplication/x-www-form-urlencoded".multipart/form-datamultipart/form-data".text/plaintext/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.
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.
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.
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.
Let data be the result of encoding the form data set using the appropriate form encoding algorithm.
Let MIME type be determined as follows:
application/x-www-form-urlencodedapplication/x-www-form-urlencoded".multipart/form-datamultipart/form-data".text/plaintext/plain".Let destination be the result of concatenating the following:
data:".;base64,".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.
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.
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:
application/x-www-form-urlencodedapplication/x-www-form-urlencoded encoding
algorithm.multipart/form-datamultipart/form-data encoding
algorithm.text/plaintext/plain encoding
algorithm.The application/x-www-form-urlencoded encoding
algorithm is as follows:
Let result be the empty string.
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.
Let charset be the preferred MIME name of the selected character encoding.
For each entry in the form data set, perform these substeps:
If the entry's name is "_charset_"
and its type is "hidden", replace its value
with charset.
If the entry's type is "file",
replace its value with the file's filename only.
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 (;).
For each character in the entry's name and value, apply the following subsubsteps:
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).
If the character is a U+0020 SPACE character, replace it with a single U+002B PLUS SIGN character (+).
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.
If this is not the first entry, append a single U+0026 AMPERSAND character (&) to result.
Append the entry's name to result.
Append a single U+003D EQUALS SIGN character (=) to result.
Append the entry's value to result.
Encode result as US-ASCII and return the resulting byte stream.
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.
The text/plain encoding
algorithm is as follows:
Let result be the empty string.
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.
Let charset be the preferred MIME name of the selected character encoding.
If the entry's name is "_charset_" and
its type is "hidden", replace its value with
charset.
If the entry's type is "file", replace
its value with the file's filename only.
For each entry in the form data set, perform these substeps:
Append the entry's name to result.
Append a single U+003D EQUALS SIGN character (=) to result.
Append the entry's value to result.
Append a U+000D CARRIAGE RETURN (CR) U+000A LINE FEED (LF) character pair to result.
Encode result using the selected character encoding and return the resulting byte stream.
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).
When the user agent is to broadcast forminput events or
broadcast formchange
events from a form element form, it must run the following steps:
Let controls be a list of all the resettable elements whose form owner is form.
forminput events, let event name be forminput. Otherwise the user agent
was to broadcast formchange events; let event name be formchange.For each element in controls, in tree order, fire a simple event named event name at the element.
details elementsummary element followed by flow content.openinterface 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 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.
summary elementdetails element.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.
command elementtypelabelicondisabledcheckedradiogrouptitle attribute has special semantics on this element.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 element represents a normal command with an associated action.
The element represents a state or option that can be toggled.
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:
type attribute is
in the Checkbox stateIf 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.
type attribute is
in the Radio stateIf 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.
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>
menu elementtype attribute is in the toolbar state: Interactive content.li elements.typelabelinterface 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:

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.
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:
hr elementoption 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)li elementlabel elementmenu element with no label attributeselect elementmenu or select element, then
append another separator.menu element with a label attributeoptgroup element with a label attributelabel 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.Once all the nodes have been processed as described above, the user agent must the post-process the menu as follows:
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.
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.
A command is the abstraction behind menu items, buttons, and links.
Commands are defined to have the following facets:
These facets are exposed on elements using the command API:
commandTypeExposes the Type facet of the command.
idExposes the ID facet of the command.
labelExposes the Label facet of the command.
titleExposes the Hint facet of the command.
iconExposes the Icon facet of the command.
accessKeyLabelExposes the Access Key facet of the command.
hiddenExposes the Hidden State facet of the command.
disabledExposes the Disabled State facet of the command.
checkedExposes the Checked State facet of the command.
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.
commandsReturns 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.
a element to define a commandAn 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.
button element to define a commandA 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.
input element to define a commandAn 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.
option element to define a commandAn 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.
command element to define
a commandA 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.
accesskey attribute on a label element to define a commandA 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.)
accesskey attribute on a legend element to define a commandA 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.)
accesskey attribute to define a command on other elementsAn 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:
click event at the element.device elementtypeinterface 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>
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.
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.