Status: Last call for comments
A form-associated element can have a relationship
with a form
element, which is called the element's
form owner. If a form-associated element is
not associated with a form
element, its form
owner is said to be null.
A form-associated element is, by default, associated
with its nearest ancestor form
element (as described below), but may have a form
attribute specified to
override this.
If a form-associated element has a form
attribute specified, then its
value must be the ID of a form
element in the element's
owner Document
.
When a form-associated element is created, its form owner must be initialized to null (no owner).
When a form-associated element is to be associated with a form, its form owner must be set to that form.
When a form-associated element's ancestor chain
changes, e.g. because it or one of its ancestors was inserted or removed from a
Document
, then the user agent must reset the form
owner of that element.
When a form-associated element's form
attribute is added, removed, or
has its value changed, then the user agent must reset the form
owner of that element.
When a form-associated element has a form
attribute and the ID of any of the
elements in the Document
changes, then the user agent
must reset the form owner of that form-associated
element.
When a form-associated element has a form
attribute and an element with an
ID is inserted
into or removed from the Document
, then the
user agent must reset the form owner of that
form-associated element.
When the user agent is to reset the form owner of a form-associated element, it must run the following steps:
If the element's form owner is not null, and
the element's form
content
attribute is not present, and the element's form owner
is its nearest form
element ancestor after the change
to the ancestor chain, then do nothing, and abort these
steps.
Let the element's form owner be null.
If the element has a form
content attribute, then run these substeps:
If the first element in the
Document
to have an ID that is case-sensitively equal to the
element's form
content
attribute's value is a form
element, then associate the
form-associated element with that form
element.
Abort the "reset the form owner" steps.
Otherwise, if the form-associated element in
question has an ancestor form
element, then associate the
form-associated element with the nearest such ancestor
form
element.
Otherwise, the element is left unassociated.
In the following non-conforming snippet:
... <form id="a"> <div id="b"></div> </form> <script> document.getElementById('b').innerHTML = '<table><tr><td><form id="c"><input id="d"></table>' + '<input id="e">'; </script> ...
The form owner of "d" would be the inner nested form "c", while the form owner of "e" would be the outer form "a".
This is because despite the association of "e" with "c" in the
HTML parser, when the innerHTML
algorithm moves the nodes
from the temporary document to the "b" element, the nodes see their
ancestor chain change, and thus all the "magic" associations done
by the parser are reset to normal ancestor associations.
This example is a non-conforming document, though, as it is a
violation of the content models to nest form
elements.
form
Returns the element's form owner.
Returns null if there isn't one.
Form-associated
elements have a form
IDL attribute, which,
on getting, must return the element's form owner, or
null if there isn't one.
Status: Last call for comments
Status: Last call for comments
The name
content
attribute gives the name of the form control, as used in form
submission and in the form
element's elements
object. If the attribute
is specified, its value must not be the empty string.
Status: Last call for comments
The disabled
content attribute is a boolean attribute.
A form control is disabled
if its disabled
attribute is
set, or if it is a descendant of a fieldset
element
whose disabled
attribute
is set and is not a descendant of that
fieldset
element's first legend
element
child, if any.
A form control that is disabled must prevent any click
events that are queued on the user interaction task
source from being dispatched on the element.
Constraint validation: If an element is disabled, it is barred from constraint validation.
The disabled
IDL
attribute must reflect the disabled
content attribute.
Form controls have a value
and a checkedness. (The latter
is only used by input
elements.) These are used to
describe how the user interacts with the control.
Status: Last call for comments
The autofocus
content attribute allows the user to indicate that a control is to
be focused as soon as the page is loaded, allowing the user to just
start typing without having to manually focus the main control.
The autofocus
attribute is
a boolean attribute.
There must not be more than one element in the document with the
autofocus
attribute
specified.
Whenever an element with the autofocus
attribute specified is
inserted into a
document whose browsing context did not have the
sandboxed automatic features browsing context flag set
when the Document
was created, the user agent should
queue a task that checks to see if the element is
focusable, and if so, runs the focusing
steps for that element. User agents may also change the
scrolling position of the document, or perform some other action
that brings the element to the user's attention. The task
source for this task is the DOM manipulation task
source.
User agents may ignore this attribute if the user has indicated (for example, by starting to type in a form control) that he does not wish focus to be changed.
Focusing the control does not imply that the user agent must focus the browser window if it has lost focus.
The autofocus
IDL attribute must reflect the content attribute of the
same name.
In the following snippet, the text control would be focused when the document was loaded.
<input maxlength="256" name="q" value="" autofocus> <input type="submit" value="Search">
Status: Last call for comments
A form control maxlength
attribute, controlled by a dirty value flag declares a limit on the number of
characters a user can input.
If an element has its form
control maxlength
attribute specified,
the attribute's value must be a valid non-negative
integer. If the attribute is specified and applying the
rules for parsing non-negative integers to its value
results in a number, then that number is the element's maximum
allowed value length. If the attribute is omitted or parsing
its value results in an error, then there is no maximum
allowed value length.
Constraint validation: If an element has a maximum allowed value length, and its dirty value flag is true, and the code-point length of the element's value is greater than the element's maximum allowed value length, then the element is suffering from being too long.
User agents may prevent the user from causing the element's value to be set to a value whose code-point length is greater than the element's maximum allowed value length.
Status: Last call for comments
Attributes for form submission can be specified both
on form
elements and on submit buttons (elements that
represent buttons that submit forms, e.g. an input
element whose type
attribute is
in the Submit Button
state).
The attributes for form submission that may be
specified on form
elements are action
, enctype
, method
, novalidate
, and target
.
The corresponding attributes for form submission
that may be specified on submit
buttons are formaction
, formenctype
, formmethod
, formnovalidate
, and formtarget
. When omitted, they
default to the values given on the corresponding attributes on the
form
element.
The action
and
formaction
content attributes, if specified, must have a value that is a
valid URL potentially surrounded by spaces.
The action of an element is
the value of the element's formaction
attribute, if the
element is a submit
button and has such an attribute, or the value of its
form owner's action
attribute, if it has one, or else the empty string.
The method
and
formmethod
content attributes are enumerated
attributes with the following keywords and states:
GET
, mapping
to the state GET, indicating
the HTTP GET method.POST
, mapping
to the state POST, indicating
the HTTP POST method.PUT
, mapping
to the state PUT, indicating
the HTTP PUT method.DELETE
, mapping
to the state DELETE, indicating
the HTTP DELETE method.The missing value default for these attributes is the GET state.
The method of an element is
one of those four states. If the element is a submit button and has a formmethod
attribute, then the
element's method is that
attribute's state; otherwise, it is the form owner's
method
attribute's state.
The enctype
and
formenctype
content attributes are enumerated
attributes with the following keywords and states:
application/x-www-form-urlencoded
" keyword and corresponding state.multipart/form-data
" keyword and corresponding state.text/plain
" keyword and corresponding state.The missing value default for these attributes is the
application/x-www-form-urlencoded
state.
The enctype of an element
is one of those three states. If the element is a submit button and has a formenctype
attribute, then the
element's enctype is that
attribute's state; otherwise, it is the form owner's
enctype
attribute's state.
The target
and
formtarget
content attributes, if specified, must have values that are valid browsing
context names or keywords.
The target of an element is
the value of the element's formtarget
attribute, if the
element is a submit
button and has such an attribute; or the value of its
form owner's target
attribute, if it has such an attribute; or, if one of the
child nodes of the head
element is a
base
element with a target
attribute, then the value of
the target
attribute of the
first such base
element; or, if there is no such
element, the empty string.
The novalidate
and formnovalidate
content attributes are boolean
attributes. If present, they indicate that the form is not to
be validated during submission.
The no-validate state of
an element is true if the element is a submit button and the element's
formnovalidate
attribute
is present, or if the element's form owner's novalidate
attribute is present,
and false otherwise.
This attribute is useful to include "save" buttons on forms that have validation constraints, to allow users to save their progress even though they haven't fully entered the data in the form. The following example shows a simple form that has two required fields. There are three buttons: one to submit the form, which requires both fields to be filled in; one to save the form so that the user can come back and fill it in later; and one to cancel the form altogether.
<form action="editor.cgi" method="post"> <p><label>Name: <input required name=fn></label></p> <p><label>Essay: <textarea name=essay></textarea></label></p> <p><input type=submit name=submit value="Submit essay"></p> <p><input type=submit formnovalidate name=save value="Save essay"></p> <p><input type=submit formnovalidate name=cancel value="Cancel"></p> </form>
The action
, method
, enctype
, and target
IDL attributes must
reflect the respective content attributes of the same
name. The noValidate
IDL
attribute must reflect the novalidate
content attribute. The
formAction
IDL
attribute must reflect the formaction
content attribute. The
formEnctype
IDL
attribute must reflect the formenctype
content attribute.
The formMethod
IDL
attribute must reflect the formmethod
content attribute. The
formNoValidate
IDL attribute must reflect the formnovalidate
content
attribute. The formTarget
IDL
attribute must reflect the formtarget
content attribute.
Status: Last call for comments
Status: Last call for comments
A listed form-associated
element is a candidate for constraint validation
except when a condition has barred the element from constraint
validation. (For example, an element is barred from
constraint validation if it is an output
or
fieldset
element.)
An element can have a custom validity error message
defined. Initially, an element must have its custom validity
error message set to the empty string. When its value is not
the empty string, the element is suffering from a custom
error. It can be set using the setCustomValidity()
method. The user agent should use the custom validity error
message when alerting the user to the problem with the
control.
An element can be constrained in various ways. The following is the list of validity states that a form control can be in, making the control invalid for the purposes of constraint validation. (The definitions below are non-normative; other parts of this specification define more precisely when each state applies or does not.)
When a control has no value but has a required
attribute (input
required
, textarea
required
).
When a control that allows arbitrary user input has a value that is not in the correct syntax (E-mail, URL).
When a control has a value that doesn't satisfy the
pattern
attribute.
When a control has a value that is too long for the
form control maxlength
attribute (input
maxlength
,
textarea
maxlength
).
When a control has a value that is too low for the min
attribute.
When a control has a value that is too high for the
max
attribute.
When a control has a value that doesn't fit the rules
given by the step
attribute.
When a control's custom validity error
message (as set by the element's setCustomValidity()
method) is not the empty string.
An element can still suffer from these states even when the element is disabled; thus these states can be represented in the DOM even if validating the form during submission wouldn't indicate a problem to the user.
An element satisfies its constraints if it is not suffering from any of the above validity states.
Status: Last call for comments
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.
Status: Last call for comments
willValidate
Returns 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
. valueMissing
Returns true if the element has no value but is a required field; false otherwise.
validity
. typeMismatch
Returns true if the element's value is not in the correct syntax; false otherwise.
validity
. patternMismatch
Returns true if the element's value doesn't match the provided pattern; false otherwise.
validity
. tooLong
Returns true if the element's value is longer than the provided maximum length; false otherwise.
validity
. rangeUnderflow
Returns true if the element's value is lower than the provided minimum; false otherwise.
validity
. rangeOverflow
Returns true if the element's value is higher than the provided maximum; false otherwise.
validity
. stepMismatch
Returns true if the element's value doesn't fit the rules given by the step
attribute; false otherwise.
validity
. customError
Returns true if the element has a custom error; false otherwise.
validity
. valid
Returns 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.
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 user agent would not actually
show a textual message in such a situation (e.g. it would show a
graphical cue instead), then the attribute must return a suitably
localized message that expresses (one or more of) the validity
constraint(s) that the control does not satisfy. 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.
Status: Last call for comments
Status: Last call for comments
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--
Status: Last call for comments
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.
Status: Last call for comments
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 Image Button state, and
either the field element does not have a
name
attribute specified, or
its name
attribute's value is
the empty string.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.
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. If
there are no selected files,
then append an entry in the form data set
with the name as the name, the empty string
as the value, and application/octet-stream
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-urlencoded
application/x-www-form-urlencoded
".multipart/form-data
multipart/form-data
".text/plain
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.
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-urlencoded
application/x-www-form-urlencoded
".multipart/form-data
multipart/form-data
".text/plain
text/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-urlencoded
application/x-www-form-urlencoded
encoding
algorithm.multipart/form-data
multipart/form-data
encoding
algorithm.text/plain
text/plain
encoding
algorithm.Status: Last call for comments
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 appropriate subsubsteps from the following list:
Replace the character with a string formed as follows:
Let s be an empty string.
For each byte b of the character when expressed in the selected character encoding in turn, run the appropriate subsubsubstep from the list below:
Append to s the Unicode character with the codepoint equal to the byte.
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).
Leave the character as is.
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.
Status: Last call for comments
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, unless the entry's
name is "_charset_
" and its type is "hidden
", in which case the field value is the
character encoding used by the aforementioned algorithm to encode
the value of the field.
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.
Status: Last call for comments
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.
Status: Last call for comments
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).
Status: Last call for comments
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.