script elementBlock-level element, strictly inline-level content, and metadata element.
src attribute, depends on the value of the type attribute.
src attribute, the element must be empty.
src
async
defer
type
interface HTMLScriptElement : HTMLElement {
attribute DOMString src;
attribute boolean async;
attribute boolean defer;
attribute DOMString type;
attribute DOMString text;
};
The script element allows authors to
include dynamic script in their documents.
When the src
attribute is set, the script element
refers to an external file. The value of the attribute must be a URI (or
IRI).
If the src
attribute is not set, then the script is given by the contents of the
element.
The language of the script may be given by the type attribute. If the attribute
is present, its value must be a valid MIME type, optionally with
parameters. [RFC2046]
The async and
defer attributes
are boolean attributes
that indicate how the script should be executed.
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 downloaded and executed immediately, before
the user agent continues parsing the page. The exact processing details
for these attributes is described below.
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.
Changing the src,
type, async, and defer attributes
dynamically has no direct effect; these attribute are only used at
specific times described below (namely, when the element is inserted into
the document).
script elements have three
associated pieces of metadata. The first is a flag indicating whether or
not the script block has been "already executed".
Initially, script elements must have
this flag unset (script blocks, when created, are not "already executed").
When a script element is cloned, the
"already executed" flag, if set, must be propagated to the clone when it
is created. The second is a flag indicating whether the element was "parser-inserted". This flag is set by the HTML parser and is used to handle document.write() calls. The third
piece of metadata is the script's
type. It is determined when the script is run, based on the
attributes on the element at that time.
Running a script: when a script block is inserted into a document, the user agent must act as follows:
If the script element has a type attribute but
its value is the empty string, or if the script element has no type attribute but
it has a language attribute, and
that attribute's value is the empty string, let the script's type for this script element be "text/javascript".
Otherwise, if the script element
has a type
attribute, let the script's type
for this script element be the value
of that attribute.
Otherwise, if the element has a language attribute, let the script's type for this script element be the concatenation of the
string "text/" followed by the value of the language attribute.
If scripting is disabled, or if the
Document has designMode enabled, or if the script element was created by an XML
parser that itself was created as part of the processing of the
innerHTML
attribute's
setter,
or if the user agent does not support the scripting
language given by the script's
type for this script
element, or if the script element
has its "already executed" flag set, then the
user agent must abort these steps at this point. The script is not
executed.
The user agent must set the element's "already executed" flag.
If the element has a src attribute, then a load for the specified
content must be started.
Later, once the load has completed, the user agent will have to complete the steps described below.
For performance reasons, user agents may start loading the script as
soon as the attribute is set, instead, in the hope that the element will
be inserted into the document. Either way, once the element is inserted
into the document, the load must have started. If the UA performs such
prefetching, but the element is never inserted in the document, or the
src attribute is
dynamically changed, then the user agent will not execute the script,
and the load will have been effectively wasted.
Then, the first of the following options that describes the situation must be followed:
defer attribute,
and the element does not have an async attribute
async attribute and a src attribute
async attribute but no src attribute, and the
list of scripts that will execute
asynchronously is not empty
src attribute and has been flagged as "parser-inserted"
src attribute
When a script completes loading: If a script whose element was added to one of the lists mentioned above completes loading while the document is still being parsed, then the parser handles it. Otherwise, when a script completes loading, the UA must run the following steps as soon as as any other scripts that may be executing have finished executing:
If the script's element is not the first element in the list, then do nothing yet. Stop going through these steps.
Otherwise, execute the script (that is, the script associated with the first element in the list).
Remove the script's element from the list (i.e. shift out the first entry in the list).
If there are any more entries in the list, and if the script associated with the element that is now the first in the list is already loaded, then jump back to step two to execute it.
If the script is not the first element in the list, then do nothing yet. Stop going through these steps.
Execute the script (the script associated with the first element in the list).
Remove the script's element from the list (i.e. shift out the first entry in the list).
If there are any more scripts in the list, and the element now at
the head of the list had no src attribute when it was added to the list,
or had one, but its associated script has finished loading, then jump
back to step two to execute the script associated with this element.
Remove the script's element from the list.
The script will be handled when the parser resumes (amazingly enough).
The download of an external script must delay the
load event.
Executing a script
block: If the load resulted in an error (for example a DNS error, or
an HTTP 404 error), then executing the script must just consist of firing an error event at the element.
If the load was successful, then first the user agent must fire a load event at the
element, and then, if scripting is enabled, and
the Document does not have designMode
enabled, and the Document is the active
document in its browsing context, the user
agent must execute the script:
If the script is from an external file, then that file must be used as the file to execute.
If the script is inline, then, for scripting languages that consist of
pure text, user agents must use the value of the DOM text attribute (defined
below) as the script to execute, and for XML-based scripting languages,
user agents must use all the child nodes of the script element as the script to execute.
In any case, the user agent must execute the script according to the semantics defined by the language associated with the script's type (see the scripting languages section below).
Scripts must be executed in the scope of the browsing context of the element's
Document.
The element's attributes' values might have changed between
when the element was inserted into the document and when the script has
finished loading, as may its other attributes; similarly, the element
itself might have been taken back out of the DOM, or had other changes
made. These changes do not in any way affect the above steps; only the
values of the attributes at the time the script element is first inserted into the
document matter.
The DOM attributes src, type, async, and defer, each must reflect the respective content attributes of the same
name.
The DOM attribute text must return a concatenation
of the contents of all the text
nodes that are direct 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 DOM
attribute.
A user agent is said to support the scripting language if the script's type matches the MIME type of a scripting language that the user agent implements.
The following lists some MIME types and the languages to which they refer:
text/javascript
text/javascript;e4x=1
User agents may support other MIME types and other languages.
When examining types to determine if they support the language, user agents must not ignore unknown MIME parameters — types with unknown parameters must be assumed to be unsupported.
noscript elementWhen scripting is disabled: metadata element, transparent block-level element, and transparent strictly inline-level content.
When scripting is enabled: metadata element, block-level element, and strictly inline-level content.
head element of an HTML document, if there are no
ancestor noscript elements.
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 does not
represent anything. 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.
The noscript element must not be
used in XML documents.
When used in HTML documents, the allowed content
model depends on whether scripting is enabled or not, and whether the
element is in a head element or not.
In a head element, if scripting is disabled, then the content model of a
noscript element must contain only
link, style, and meta
elements. If scripting is enabled, then the
content model of a noscript element
is text, except that invoking the HTML fragment parsing algorithm
with the noscript element as the context and the text contents as the input must result in a list of nodes that consists only of
link, style, and meta
elements.
Outside of head elements, if scripting is disabled, then the content model of a
noscript element 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).
Outside of head elements, if scripting is enabled, then the content model of a
noscript element is 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.
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.)
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.
All these contortions are required because, for historical
reasons, the noscript element causes
the HTML parser to act differently based on whether
scripting is enabled or not. The element is not allowed in XML, because in
XML the parser is not affected by such state, and thus the element would
not have the desired effect.
event-source elementBlock-level element, strictly inline-level content, and metadata element.
src
interface HTMLEventSourceElement : HTMLElement {
attribute DOMString src;
};
The event-source element
represents a target for events generated by a remote server.
The src
attribute, if specified, must give a URI (or IRI) pointing to a resource
that uses the application/x-dom-event-stream format.
When the element is inserted into the document, if it has the src attribute
specified, the user agent must act as if the addEventSource() method on the event-source element had been invoked with
the URI resulting from resolving the src attribute's value to an absolute URI.
While the element is in a document, if its src attribute is
mutated, the user agent must act as if first the removeEventSource() method on the
event-source element had been
invoked with the URI resulting from resolving the old value of the
attribute to an absolute URI, and then as if the addEventSource() method on the element
had been invoked with the URI resulting from resolving the new
value of the src attribute to an absolute URI.
When the element is removed from the document, if it has the src attribute
specified, or, when the src attribute is about to be removed, the user
agent must act as if the removeEventSource() method on the
event-source element had been
invoked with the URI resulting from resolving the src attribute's
value to an absolute URI.
There can be more than one event-source element per document, but
authors should take care to avoid opening multiple connections to the same
server as HTTP recommends a limit to the number of simultaneous
connections that a user agent can open per server.
The src DOM
attribute must reflect the content attribute of the same name.