Scripts allow authors to add interactivity to their documents.
Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting.
For example, instead of using script to show or hide a section
to show more details, the details
element could be
used.
Authors are also encouraged to make their applications degrade gracefully in the absence of scripting support.
For example, if an author provides a link in a table header to dynamically resort the table, the link could also be made to function without scripts by requesting the sorted table from the server.
script
elementsrc
attribute, depends on the value of the type
attribute, but must match
script content restrictions.src
attribute, the element must be either empty or contain only
script documentation that also matches script
content restrictions.src
type
charset
async
defer
crossorigin
interface HTMLScriptElement : HTMLElement { attribute DOMString src; attribute DOMString type; attribute DOMString charset; attribute boolean async; attribute boolean defer; attribute DOMString crossOrigin; attribute DOMString text; };
The script
element allows authors to include dynamic script and data blocks in
their documents. The element does not represent content for the
user.
When used to include dynamic scripts, the scripts may either be embedded inline or may be
imported from an external file using the src
attribute. If
the language is not that described by "text/javascript
", then the type
attribute must be present, as described below. Whatever
language is used, the contents of the script
element must conform with the
requirements of that language's specification.
When used to include data blocks (as opposed to scripts), the data must be embedded inline, the
format of the data must be given using the type
attribute,
the src
attribute must not be specified, and the contents of
the script
element must conform to the requirements defined for the format used.
The type
attribute gives the language of the
script or format of the data. If the attribute is present, its value must be a valid MIME
type. The charset
parameter must not be specified. The default, which
is used if the attribute is absent, is "text/javascript
".
The src
attribute, if specified, gives the
address of the external script resource to use. The value of the attribute must be a valid
non-empty URL potentially surrounded by spaces identifying a script resource of the type
given by the type
attribute, if the attribute is present, or
of the type "text/javascript
", if the attribute is absent. A resource is a
script resource of a given type if that type identifies a scripting language and the resource
conforms with the requirements of that language's specification.
The charset
attribute gives the character
encoding of the external script resource. The attribute must not be specified if the src
attribute is not present. If the attribute is set, its value
must be an ASCII case-insensitive match for the name of an encoding, and must specify the same encoding as
the charset
parameter of the Content-Type
metadata of the external file, if any. [ENCODING]
The async
and defer
attributes are boolean attributes that indicate how the script should be executed. The defer
and async
attributes
must not be specified if the src
attribute is not
present.
There are three possible modes that can be selected using these attributes. If the async
attribute is present, then the script will be executed
asynchronously, as soon as it is available. If the async
attribute is not present but the defer
attribute is
present, then the script is executed when the page has finished parsing. If neither attribute is
present, then the script is fetched and executed immediately, before the user agent continues
parsing the page.
The exact processing details for these attributes are, for mostly historical
reasons, somewhat non-trivial, involving a number of aspects of HTML. The implementation
requirements are therefore by necessity scattered throughout the specification. The algorithms
below (in this section) describe the core of this processing, but these algorithms reference and
are referenced by the parsing rules for script
start and end tags in HTML, in foreign content,
and in XML, the rules for the document.write()
method, the handling of scripting, etc.
The defer
attribute may be specified even if the async
attribute is specified, to cause legacy Web browsers that
only support defer
(and not async
) to fall back to the defer
behavior instead of the synchronous blocking behavior that
is the default.
The crossorigin
attribute is a
CORS settings attribute. It controls, for scripts that are obtained from other origins, whether error information will be exposed.
Changing the src
, type
, charset
, async
, defer
, and crossorigin
attributes dynamically has no direct effect;
these attribute are only used at specific times described below.
A script
element has several associated pieces of state.
The first is a flag indicating whether or not the script block has been "already
started". Initially, script
elements must have this flag unset (script blocks,
when created, are not "already started"). The cloning
steps for script
elements must set the "already started" flag on the copy if
it is set on the element being cloned.
The second is a flag indicating whether the element was "parser-inserted".
Initially, script
elements must have this flag unset. It is set by the HTML
parser and the XML parser on script
elements they insert and
affects the processing of those elements.
The third is a flag indicating whether the element will "force-async". Initially,
script
elements must have this flag set. It is unset by the HTML parser
and the XML parser on script
elements they insert. In addition, whenever
a script
element whose "force-async" flag is set has a async
content attribute added, the element's
"force-async" flag must be unset.
The fourth is a flag indicating whether or not the script block is "ready to be
parser-executed". Initially, script
elements must have this flag unset (script
blocks, when created, are not "ready to be parser-executed"). This flag is used only for elements
that are also "parser-inserted", to let the parser know when to execute the
script.
The last few pieces of state are the script block's type, the
script block's character encoding, and the script block's fallback character
encoding. They are determined when the script is prepared, based on the attributes on
the element at that time, and the Document
of the script
element.
When a script
element that is not marked as being "parser-inserted"
experiences one of the events listed in the following list, the user agent must synchronously
prepare the script
element:
script
element gets inserted
into a document, at the time the node is inserted
according to the DOM, after any other script
elements inserted at the same time that
are earlier in the Document
in tree order.script
element is in a Document
and a node or
document fragment is inserted into the
script
element, after any script
elements inserted at that time.script
element is in a Document
and has a src
attribute set where previously the element had no such
attribute.To prepare a script, the user agent must act as follows:
If the script
element is marked as having "already started", then
the user agent must abort these steps at this point. The script is not executed.
If the element has its "parser-inserted" flag set, then set was-parser-inserted to true and unset the element's "parser-inserted" flag. Otherwise, set was-parser-inserted to false.
This is done so that if parser-inserted script
elements fail to run
when the parser tries to run them, e.g. because they are empty or specify an unsupported
scripting language, another script can later mutate them and cause them to run again.
If was-parser-inserted is true and the element does not have an async
attribute, then set the element's
"force-async" flag to true.
This is done so that if a parser-inserted script
element fails to
run when the parser tries to run it, but it is later executed after a script dynamically updates
it, it will execute asynchronously even if the async
attribute isn't set.
If the element has no src
attribute, and its child
nodes, if any, consist only of comment nodes and empty Text
nodes, then the user
agent must abort these steps at this point. The script is not executed.
If the element is not in a Document
, then the user agent must abort
these steps at this point. The script is not executed.
If either:
script
element has a type
attribute
and its value is the empty string, orscript
element has no type
attribute
but it has a language
attribute and that
attribute's value is the empty string, orscript
element has neither a type
attribute nor a language
attribute, then...let the script block's type for this script
element be "text/javascript
".
Otherwise, if the script
element has a type
attribute, let the script block's type for this
script
element be the value of that attribute with any leading or trailing
sequences of space characters removed.
Otherwise, the element has a non-empty language
attribute; let the script block's type for this script
element be the
concatenation of the string "text/
" followed by the value of the language
attribute.
The language
attribute is never
conforming, and is always ignored if there is a type
attribute present.
If the user agent does not support the scripting language given by the
script block's type for this script
element, then the user agent must abort
these steps at this point. The script is not executed.
If was-parser-inserted is true, then flag the element as "parser-inserted" again, and set the element's "force-async" flag to false.
The user agent must set the element's "already started" flag.
The state of the element at this moment is later used to determine the script source.
If the element is flagged as "parser-inserted", but the element's
Document
is not the Document
of the parser that created the element,
then abort these steps.
If scripting is disabled for the script
element, then the user agent must abort these steps at this point. The script is not
executed.
The definition of scripting is disabled
means that, amongst others, the following scripts will not execute: scripts in
XMLHttpRequest
's responseXML
documents, scripts in DOMParser
-created documents, scripts in documents created by
XSLTProcessor
's transformToDocument
feature, and scripts
that are first inserted by a script into a Document
that was created using the
createDocument()
API. [XHR] [DOMPARSING] [DOM]
If the script
element has an event
attribute and a for
attribute, then run these substeps:
Let for be the value of the for
attribute.
Let event be the value of the event
attribute.
Strip leading and trailing whitespace from event and for.
If for is not an ASCII case-insensitive match for the
string "window
", then the user agent must abort these steps at this
point. The script is not executed.
If event is not an ASCII case-insensitive match for
either the string "onload
" or the string "onload()
", then the user agent must abort these steps at this point. The script
is not executed.
If the script
element has a charset
attribute, then let the script block's character encoding for this
script
element be the result of getting an encoding from the value of
the charset
attribute.
Otherwise, let the script block's fallback character encoding for this
script
element be the same as the
encoding of the document itself.
Only one of these two pieces of state is set.
If the element has a src
content attribute, run these
substeps:
Let src be the value of the element's src
attribute.
If src is the empty string, queue a task to fire
a simple event named error
at the element, and abort
these steps.
Resolve src relative to the element.
If the previous step failed, queue a task to fire a simple
event named error
at the element, and abort these
steps.
Do a potentially CORS-enabled fetch of the resulting
absolute URL, with the mode being the state of the element's crossorigin
content attribute, the origin being the origin of the script
element's
Document
, and the default origin behaviour set to taint.
The resource obtained in this fashion can be either CORS-same-origin or CORS-cross-origin. This only affects how error reporting happens.
For historical reasons, if the URL is a javascript:
URL, then the user agent must not, despite
the requirements in the definition of the fetching algorithm,
actually execute the script in the URL; instead the user agent must act as if it had received
an empty HTTP 400 response.
For performance reasons, user agents may start fetching the script (as defined above) as
soon as the src
attribute is set, instead, in the hope
that the element will be inserted into the document (and that the crossorigin
attribute won't change value in the
meantime). Either way, once the element is inserted into the document, the load must have started as described in this
step. If the UA performs such prefetching, but the element is never inserted in the document,
or the src
attribute is dynamically changed, or the crossorigin
attribute is dynamically changed, then the
user agent will not execute the script so obtained, and the fetching process will have been
effectively wasted.
Then, the first of the following options that describes the situation must be followed:
src
attribute, and the element has a defer
attribute, and
the element has been flagged as "parser-inserted", and the element does not have
an async
attributeThe element must be added to the end of the list of scripts that will execute when the
document has finished parsing associated with the Document
of the parser
that created the element.
The task that the networking task source places on the task queue once the fetching algorithm has completed must set the element's "ready to be parser-executed" flag. The parser will handle executing the script.
src
attribute, and the element has been flagged as
"parser-inserted", and the element does not have an async
attributeThe element is the pending parsing-blocking script of the
Document
of the parser that created the element. (There can only be one such
script per Document
at a time.)
The task that the networking task source places on the task queue once the fetching algorithm has completed must set the element's "ready to be parser-executed" flag. The parser will handle executing the script.
src
attribute, and the element has been flagged as
"parser-inserted", and either the parser that created the script
is
an XML parser or it's an HTML parser whose script nesting
level is not greater than one, and the Document
of the HTML
parser or XML parser that created the script
element has
a style sheet that is blocking scriptsThe element is the pending parsing-blocking script of the
Document
of the parser that created the element. (There can only be one such
script per Document
at a time.)
Set the element's "ready to be parser-executed" flag. The parser will handle executing the script.
src
attribute, does not have an async
attribute, and does not have the
"force-async" flag setThe element must be added to the end of the list of scripts that will execute in order
as soon as possible associated with the Document
of the script
element at the time the prepare a script algorithm started.
The task that the networking task source places on the task queue once the fetching algorithm has completed must run the following steps:
If the element is not now the first element in the list of scripts that will execute in order as soon as possible to which it was added above, then mark the element as ready but abort these steps without executing the script yet.
Execution: Execute the script block corresponding to the first script element in this list of scripts that will execute in order as soon as possible.
Remove the first element from this list of scripts that will execute in order as soon as possible.
If this list of scripts that will execute in order as soon as possible is still not empty and the first entry has already been marked as ready, then jump back to the step labeled execution.
src
attributeThe element must be added to the set of scripts that will execute as soon as
possible of the Document
of the script
element at the time the
prepare a script algorithm started.
The task that the networking task source places on the task queue once the fetching algorithm has completed must execute the script block and then remove the element from the set of scripts that will execute as soon as possible.
Fetching an external script must delay the load event of the element's document until the task that is queued by the networking task source once the resource has been fetched (defined above) has been run.
The pending parsing-blocking script of a Document
is used by the
Document
's parser(s).
If a script
element that blocks a parser gets moved to another
Document
before it would normally have stopped blocking that parser, it nonetheless
continues blocking that parser until the condition that causes it to be blocking the parser no
longer applies (e.g. if the script is a pending parsing-blocking script because there
was a style sheet that is blocking scripts when it was parsed, but then the script is
moved to another Document
before the style sheet loads, the script still blocks the
parser until the style sheets are all loaded, at which time the script executes and the parser is
unblocked).
When the user agent is required to execute a script block, it must run the following steps:
If the element is flagged as "parser-inserted", but the element's
Document
is not the Document
of the parser that created the element,
then abort these steps.
Jump to the appropriate set of steps from the list below:
Executing the script block must just consist of firing
a simple event named error
at the element.
Executing the script block must consist of running the following steps. For the purposes of
these steps, the script is considered to be from an external file if, while the
prepare a script algorithm above was running for this script, the
script
element had a src
attribute
specified.
Initialize the script block's source as follows:
The contents of that file, interpreted as a Unicode string, are the script source.
To obtain the Unicode string, the user agent run the following steps:
If the resource's Content Type metadata, if any, specifies a character encoding, and the user agent supports that encoding, then let character encoding be that encoding, and jump to the bottom step in this series of steps.
If the algorithm above set the script block's character encoding, then let character encoding be that encoding, and jump to the bottom step in this series of steps.
Let character encoding be the script block's fallback character encoding.
If the specification for the script block's type gives specific rules for decoding files in that format to Unicode, follow them, using character encoding as the character encoding specified by higher-level protocols, if necessary.
Otherwise, decode the file to Unicode, using character encoding as the fallback encoding.
The decode algorithm overrides character encoding if the file contains a BOM.
The external file is the script source. When it is later executed, it must be interpreted in a manner consistent with the specification defining the language given by the script block's type.
The value of the text
IDL attribute at the time
the element's "already started" flag was last set is the script source.
The child nodes of the script
element at the time the element's
"already started" flag was last set are the script source.
Fire a simple event named beforescriptexecute
that bubbles and is cancelable
at the script
element.
If the event is canceled, then abort these steps.
If the script is from an external file, then increment the
ignore-destructive-writes counter of the script
element's
Document
. Let neutralized doc be that
Document
.
Let old script element be the value to which the
Document
element's currentScript
object was most recently
initialized.
Initialize the Document
element's currentScript
object to the script
element.
Create a script from the
script
element node, using the script block's source, the
URL from which the script was obtained, and the script block's
type.
If the script came from a resource that was fetched in the steps above, and the resource was CORS-cross-origin, then pass the muted errors flag to the create a script from a node algorithm.
This is where the script is compiled and actually executed.
Initialize the Document
element's currentScript
object to old script
element.
Decrement the ignore-destructive-writes counter of neutralized doc, if it was incremented in the earlier step.
Fire a simple event named afterscriptexecute
that bubbles (but is not
cancelable) at the script
element.
If the script is from an external file, fire a simple event named load
at the script
element.
Otherwise, the script is internal; queue a task to fire a simple
event named load
at the script
element.
The IDL attributes src
, type
, charset
, defer
, each must reflect the respective
content attributes of the same name.
The crossOrigin
IDL attribute must
reflect the crossorigin
content
attribute, limited to only known values.
The async
IDL attribute controls whether the
element will execute asynchronously or not. If the element's "force-async" flag is
set, then, on getting, the async
IDL attribute must return
true, and on setting, the "force-async" flag must first be unset, and then the
content attribute must be removed if the IDL attribute's new value is false, and must be set to
the empty string if the IDL attribute's new value is true. If the element's
"force-async" flag is not set, the IDL attribute must reflect
the async
content attribute.
text
[ = value ]Returns the contents of the element, ignoring child nodes that aren't Text
nodes.
Can be set, to replace the element's children with the given value.
The IDL attribute text
must return a
concatenation of the contents of all the Text
nodes that are children of the
script
element (ignoring any other nodes such as comments or elements), in tree
order. On setting, it must act the same way as the textContent
IDL attribute.
When inserted using the document.write()
method, script
elements execute (typically synchronously), but when inserted using
innerHTML
and outerHTML
attributes, they do not execute at all.
In this example, two script
elements are used. One embeds an external script, and
the other includes some data.
<script src="game-engine.js"></script> <script type="text/x-game-map"> ........U.........e o............A....e .....A.....AAA....e .A..AAA...AAAAA...e </script>
The data in this case might be used by the script to generate the map of a video game. The data doesn't have to be used that way, though; maybe the map data is actually embedded in other parts of the page's markup, and the data block here is just used by the site's search engine to help users who are looking for particular features in their game maps.
The following sample shows how a script element can be used to define a function that is then
used by other parts of the document. It also shows how a script
element can be used
to invoke script while the document is being parsed, in this case to initialize the form's
output.
<script> function calculate(form) { var price = 52000; if (form.elements.brakes.checked) price += 1000; if (form.elements.radio.checked) price += 2500; if (form.elements.turbo.checked) price += 5000; if (form.elements.sticker.checked) price += 250; form.elements.result.value = price; } </script> <form name="pricecalc" onsubmit="return false" onchange="calculate(this)"> <fieldset> <legend>Work out the price of your car</legend> <p>Base cost: £52000.</p> <p>Select additional options:</p> <ul> <li><label><input type=checkbox name=brakes> Ceramic brakes (£1000)</label></li> <li><label><input type=checkbox name=radio> Satellite radio (£2500)</label></li> <li><label><input type=checkbox name=turbo> Turbo charger (£5000)</label></li> <li><label><input type=checkbox name=sticker> "XZ" sticker (£250)</label></li> </ul> <p>Total: £<output name=result></output></p> </fieldset> <script> calculate(document.forms.pricecalc); </script> </form>
A user agent is said to support the scripting language if each component of the script block's type is an ASCII case-insensitive match for the corresponding component in the MIME type string of a scripting language that the user agent implements.
The following lists the MIME type strings that user agents must recognize, and the languages to which they refer:
application/ecmascript
"application/javascript
"application/x-ecmascript
"application/x-javascript
"text/ecmascript
"text/javascript
"text/javascript1.0
"text/javascript1.1
"text/javascript1.2
"text/javascript1.3
"text/javascript1.4
"text/javascript1.5
"text/jscript
"text/livescript
"text/x-ecmascript
"text/x-javascript
"User agents may support other MIME types for other languages, but must not support other MIME types for the languages in the list above. User agents are not required to support the languages listed above.
The following MIME types (with or without parameters) must not be interpreted as scripting languages:
text/plain
"
text/xml
"
application/octet-stream
"
application/xml
"
These types are explicitly listed here because they are poorly-defined types that are nonetheless likely to be used as formats for data blocks, and it would be problematic if they were suddenly to be interpreted as script by a user agent.
When examining types to determine if they represent supported languages, user agents must not ignore MIME parameters. Types are to be compared including all parameters.
For example, types that include the charset
parameter will
not be recognized as referencing any of the scripting languages listed above.
script
elementsThe textContent
of a script
element must match the script
production in the following ABNF, the character set for which is Unicode.
[ABNF]
script = data1 *( escape [ script-start data3 ] "-->" data1 ) [ escape ] escape = "<!--" data2 *( script-start data3 script-end data2 ) data1 = < any string that doesn't contain a substring that matches not-data1 > not-data1 = "<!--" data2 = < any string that doesn't contain a substring that matches not-data2 > not-data2 = script-start / "-->" data3 = < any string that doesn't contain a substring that matches not-data3 > not-data3 = script-end / "-->" script-start = lt s c r i p t tag-end script-end = lt slash s c r i p t tag-end lt = %x003C ; "<" (U+003C) character slash = %x002F ; "/" (U+002F) character s = %x0053 ; U+0053 LATIN CAPITAL LETTER S s =/ %x0073 ; U+0073 LATIN SMALL LETTER S c = %x0043 ; U+0043 LATIN CAPITAL LETTER C c =/ %x0063 ; U+0063 LATIN SMALL LETTER C r = %x0052 ; U+0052 LATIN CAPITAL LETTER R r =/ %x0072 ; U+0072 LATIN SMALL LETTER R i = %x0049 ; U+0049 LATIN CAPITAL LETTER I i =/ %x0069 ; U+0069 LATIN SMALL LETTER I p = %x0050 ; U+0050 LATIN CAPITAL LETTER P p =/ %x0070 ; U+0070 LATIN SMALL LETTER P t = %x0054 ; U+0054 LATIN CAPITAL LETTER T t =/ %x0074 ; U+0074 LATIN SMALL LETTER T tag-end = %x0009 ; "tab" (U+0009) tag-end =/ %x000A ; "LF" (U+000A) tag-end =/ %x000C ; "FF" (U+000C) tag-end =/ %x0020 ; U+0020 SPACE tag-end =/ %x002F ; "/" (U+002F) tag-end =/ %x003E ; ">" (U+003E)
When a script
element contains script documentation, there are
further restrictions on the contents of the element, as described in the section below.
If a script
element's src
attribute is
specified, then the contents of the script
element, if any, must be such that the
value of the text
IDL attribute, which is derived from the
element's contents, matches the documentation
production in the following
ABNF, the character set for which is Unicode. [ABNF]
documentation = *( *( space / tab / comment ) [ line-comment ] newline ) comment = slash star *( not-star / star not-slash ) 1*star slash line-comment = slash slash *not-newline ; characters tab = %x0009 ; "tab" (U+0009) newline = %x000A ; "LF" (U+000A) space = %x0020 ; U+0020 SPACE star = %x002A ; "*" (U+002A) slash = %x002F ; "/" (U+002F) not-newline = %x0000-0009 / %x000B-10FFFF ; a Unicode character other than "LF" (U+000A) not-star = %x0000-0029 / %x002B-10FFFF ; a Unicode character other than "*" (U+002A) not-slash = %x0000-002E / %x0030-10FFFF ; a Unicode character other than "/" (U+002F)
This corresponds to putting the contents of the element in JavaScript comments.
This requirement is in addition to the earlier restrictions on the syntax of
contents of script
elements.
This allows authors to include documentation, such as license information or API information,
inside their documents while still referring to external script files. The syntax is constrained
so that authors don't accidentally include what looks like valid script while also providing a
src
attribute.
<script src="cool-effects.js"> // create new instances using: // var e = new Effect(); // start the effect using .play, stop using .stop: // e.play(); // e.stop(); </script>
script
elements and XSLTThis section is non-normative.
This specification does not define how XSLT interacts with the
script
element. However, in the absence of another
specification actually defining this, here are some guidelines for
implementors, based on existing implementations:
When an XSLT transformation program is triggered by an <?xml-stylesheet?>
processing instruction and
the browser implements a direct-to-DOM transformation,
script
elements created by the XSLT processor need to
be marked "parser-inserted" and run in document order
(modulo scripts marked defer
or async
), asynchronously
while the transformation is occurring.
The XSLTProcessor.transformToDocument()
method adds elements to a Document
that is not in a
browsing context, and, accordingly, any
script
elements they create need to have their
"already started" flag set in the prepare a
script algorithm and never get executed (scripting is disabled). Such
script
elements still need to be marked
"parser-inserted", though, such that their async
IDL attribute will return
false in the absence of an async
content attribute.
The XSLTProcessor.transformToFragment()
method needs to create a fragment that is equivalent to one built
manually by creating the elements using document.createElementNS()
.
For instance, it needs to create script
elements that
aren't "parser-inserted" and that don't have their
"already started" flag set, so that they will execute
when the fragment is inserted into a document.
The main distinction between the first two cases and the last
case is that the first two operate on Document
s and the
last operates on a fragment.
noscript
elementhead
element of an HTML document, if there are no ancestor noscript
elements.noscript
elements.head
element: in any order, zero or more link
elements, zero or more style
elements, and zero or more meta
elements.head
element: transparent, but there must be no noscript
element descendants.HTMLElement
.The noscript
element represents nothing
if scripting is enabled, and
represents its children if scripting is disabled. It is used
to present different markup to user agents that support scripting
and those that don't support scripting, by affecting how the
document is parsed.
When used in HTML documents, the allowed content model is as follows:
head
element, if scripting is disabled for the
noscript
elementThe noscript
element must contain only
link
, style
, and meta
elements.
head
element, if scripting is enabled for the
noscript
elementThe noscript
element must contain only text,
except that invoking the HTML fragment parsing
algorithm with
the noscript
element as the context element and the
text contents as the input must result in a
list of nodes that consists only of link
,
style
, and meta
elements that would be
conforming if they were children of the noscript
element, and no parse
errors.
head
elements, if scripting is disabled for the
noscript
elementThe noscript
element's content model is
transparent, with the additional restriction that a
noscript
element must not have a noscript
element as an ancestor (that is, noscript
can't be
nested).
head
elements, if scripting is enabled for the
noscript
elementThe noscript
element must contain only text,
except that the text must be such that running the following
algorithm results in a conforming document with no
noscript
elements and no script
elements, and such that no step in the algorithm causes an
HTML parser to flag a parse error:
script
element from the
document.noscript
element in the
document. For every noscript
element in that list,
perform the following steps:
noscript
element.noscript
element, and call these
elements the before children.noscript
element, and
call these elements the after children.Text
node children of the noscript
element.innerHTML
attribute of the parent element to the value
of s. (This, as a side-effect, causes the
noscript
element to be removed from the
document.)All these contortions are required because, for
historical reasons, the noscript
element is handled
differently by the HTML parser based on whether scripting was enabled or not when the
parser was invoked.
The noscript
element must not be used in XML
documents.
The noscript
element is only effective
in the HTML syntax, it has no effect in the XHTML
syntax. This is because the way it works is by essentially
"turning off" the parser when scripts are enabled, so that the
contents of the element are treated as pure text and not as real
elements. XML does not define a mechanism by which to do this.
The noscript
element has no other requirements. In
particular, children of the noscript
element are not
exempt from form submission, scripting, and so forth,
even when scripting is enabled
for the element.
In the following example, a noscript
element is
used to provide fallback for a script.
<form action="calcSquare.php"> <p> <label for=x>Number</label>: <input id="x" name="x" type="number"> </p> <script> var x = document.getElementById('x'); var output = document.createElement('p'); output.textContent = 'Type a number; it will be squared right then!'; x.form.appendChild(output); x.form.onsubmit = function () { return false; } x.oninput = function () { var v = x.valueAsNumber; output.textContent = v + ' squared is ' + v * v; }; </script> <noscript> <input type=submit value="Calculate Square"> </noscript> </form>
When script is disabled, a button appears to do the calculation on the server side. When script is enabled, the value is computed on-the-fly instead.
The noscript
element is a blunt
instrument. Sometimes, scripts might be enabled, but for some
reason the page's script might fail. For this reason, it's
generally better to avoid using noscript
, and to
instead design the script to change the page from being a
scriptless page to a scripted page on the fly, as in the next
example:
<form action="calcSquare.php"> <p> <label for=x>Number</label>: <input id="x" name="x" type="number"> </p> <input id="submit" type=submit value="Calculate Square"> <script> var x = document.getElementById('x'); var output = document.createElement('p'); output.textContent = 'Type a number; it will be squared right then!'; x.form.appendChild(output); x.form.onsubmit = function () { return false; } x.oninput = function () { var v = x.valueAsNumber; output.textContent = v + ' squared is ' + v * v; }; var submit = document.getElementById('submit'); submit.parentNode.removeChild(submit); </script> </form>
The above technique is also useful in XHTML, since
noscript
is not supported in the XHTML
syntax.