GeezerVison is showing html.spec.whatwg.org — HTML Standard
- 2 Common infrastructure
- 2.1 Terminology
- 2.1.1 Parallelism
- 2.1.2 Resources
- 2.1.3 XML compatibility
- 2.1.4 DOM trees
- 2.1.5 Scripting
- 2.1.6 Plugins
- 2.1.7 Character encodings
- 2.1.8 Conformance classes
- 2.1.9 Dependencies
- 2.1.10 Extensibility
- 2.1.11 Interactions with XPath and XSLT
- 2.2 Policy-controlled features
2 Common infrastructure
This specification depends on Infra. [INFRA]
2.1 Terminology
This specification refers to both HTML and XML attributes and IDL attributes, often in the same
context. When it is not clear which is being referred to, they are referred to as content attributes for HTML and XML attributes,
and IDL attributes for those defined on IDL interfaces. Similarly, the term
"properties" is used for both JavaScript object properties and CSS properties. When these are
ambiguous they are qualified as object properties and CSS properties respectively.
Generally, when the specification states that a feature applies to the HTML syntax
or the XML syntax, it also includes the other. When a feature specifically only
applies to one of the two languages, it is called out by explicitly stating that it does not apply
to the other format, as in "for HTML, ... (this does not apply to XML)".
This specification uses the term document to refer to any use of HTML,
ranging from short static documents to long essays or reports with rich multimedia, as well as to
fully-fledged interactive applications. The term is used to refer both to Document
objects and their descendant DOM trees, and to serialized byte streams using the HTML syntax or the XML syntax, depending
on context.
In the context of the DOM structures, the terms HTML
document and XML document are used as defined in
DOM, and refer specifically to two different modes that Document objects
can find themselves in. [DOM] (Such uses are always hyperlinked to their
definition.)
In the context of byte streams, the term HTML document refers to resources labeled as
text/html, and the term XML document refers to resources labeled with an XML
MIME type.
For simplicity, terms such as shown, displayed, and
visible might sometimes be used when referring to the way a document is
rendered to the user. These terms are not meant to imply a visual medium; they must be considered
to apply to other media in equivalent ways.
2.1.1 Parallelism
To run steps in parallel means those steps are to be run, one after another,
at the same time as other logic in the standard (e.g., at the same time as the event
loop). This standard does not define the precise mechanism by which this is achieved, be it
time-sharing cooperative multitasking, fibers, threads, processes, using different hyperthreads,
cores, CPUs, machines, etc. By contrast, an operation that is to run immediately must
interrupt the currently running task, run itself, and then resume the previously running task.
For guidance on writing specifications that leverage parallelism, see Dealing with the event loop from other specifications.
To avoid race conditions between different in parallel algorithms that operate on
the same data, a parallel queue can be used.
A parallel queue represents a queue of algorithm steps that must be run in
series.
A parallel queue has an algorithm queue (a queue),
initially empty.
To start a new parallel queue, run the following steps:
Let parallelQueue be a new parallel queue. -
Run the following steps in parallel:
-
While true:
Let steps be the result of dequeuing from
parallelQueue's algorithm queue. If steps is not nothing, then run steps. Assert: running steps did not throw an exception, as steps
running in parallel are not allowed to throw.
Implementations are not expected to implement this as a continuously running
loop. Algorithms in standards are to be easy to understand and are not necessarily great for
battery life or performance.
Return parallelQueue.
Steps running in parallel can themselves run other steps in in
parallel. E.g., inside a parallel queue it can be useful to run a series of
steps in parallel with the queue.
Imagine a standard defined nameList (a list), along with a method to
add a name to nameList, unless nameList already contains name, in which case it rejects.
The following solution suffers from race conditions:
Two invocations of the above could run simultaneously, meaning name isn't in
nameList during step 3.1, but it might be added before step 3.3 runs,
meaning name ends up in nameList twice.
Parallel queues solve this. The standard would let nameListQueue be the result of
starting a new parallel queue and define the name-adding steps as follows:
The steps would now queue and the race is avoided.
2.1.2 Resources
The specification uses the term supported when referring to whether a user
agent has an implementation capable of decoding the semantics of an external resource. A format or
type is said to be supported if the implementation can process an external resource of that
format or type without critical aspects of the resource being ignored. Whether a specific resource
is supported can depend on what features of the resource's format are in use.
For example, a PNG image would be considered to be in a supported format if its
pixel data could be decoded and rendered, even if, unbeknownst to the implementation, the image
also contained animation data.
An MPEG-4 video file would not be considered to be in a supported format if the
compression format used was not supported, even if the implementation could determine the
dimensions of the movie from the file's metadata.
What some specifications, in particular the HTTP specifications, refer to as a
representation is referred to in this specification as a resource.
[HTTP]
A resource's critical subresources are those that the resource needs to have
available to be correctly processed. Which resources are considered critical or not is defined by
the specification that defines the resource's format.
For CSS style sheets, we tentatively define here that
their critical subresources are other style sheets imported via @import
rules, including those indirectly imported by other imported style sheets.
This definition is not fully interoperable; furthermore, some user agents seem to
count resources like background images or web fonts as critical subresources. Ideally, the CSS
Working Group would define this; see w3c/csswg-drafts issue #1088 to track
progress on that front.
2.1.3 XML compatibility
To ease migration from HTML to XML, user agents conforming to this
specification will place elements in HTML in the http://www.w3.org/1999/xhtml namespace, at least for the purposes of the DOM and
CSS. The term "HTML elements" refers to any element in that namespace, even in
XML documents.
Except where otherwise stated, all elements defined or mentioned in this specification are in
the HTML namespace ("http://www.w3.org/1999/xhtml"), and all
attributes defined or mentioned in this specification have no namespace.
The term element type is used to refer to the set of elements that have a given
local name and namespace. For example, button elements are elements with the element
type button, meaning they have the local name "button" and
(implicitly as defined above) the HTML namespace.
2.1.4 DOM trees
When it is stated that some element or attribute is ignored, or
treated as some other value, or handled as if it was something else, this refers only to the
processing of the node after it is in the DOM. A user agent must not mutate the
DOM in such situations.
A content attribute is said to change value only if its new value is
different than its previous value; setting an attribute to a value it already has does not change
it.
The term empty, when used for an attribute value, Text node,
or string, means that the length of the text is zero (i.e., not even containing controls or U+0020 SPACE).
An HTML element can have specific HTML element insertion steps, HTML element
post-connection steps, HTML element removing steps, and HTML element moving
steps all defined for the element's local
name.
The removing steps for the HTML Standard, given
removedNode, isSubtreeRoot, and oldAncestor, are defined as the
following:
Let document be removedNode's node document. -
If document's focused area is
removedNode, then set document's focused area to document's viewport, and set
document's relevant global object's navigation API's focus changed during ongoing
navigation to false.
This does not perform the unfocusing steps,
focusing steps, or focus update steps, and thus no blur or change events are
fired.
If removedNode is an element whose namespace is the HTML namespace, and this
standard defines HTML element removing steps
for removedNode's local name, then
run the corresponding HTML element removing steps given removedNode,
isSubtreeRoot, and oldAncestor. If removedNode is a form-associated element with a non-null
form owner and removedNode and its form owner are no longer
in the same tree, then reset the form owner of
removedNode. If removedNode's popover attribute is not in
the No Popover state, then run the hide
popover algorithm given removedNode, false, false, false, and null.
A node becomes connected when the insertion steps are invoked with it as the argument and it
is now connected. Analogously, a node becomes disconnected when the removing
steps are invoked with it as the argument and it is now no longer
connected.
2.1.5 Scripting
The construction "a Foo object", where Foo is
actually an interface, is sometimes used instead of the more accurate "an object implementing the
interface Foo".
An IDL attribute is said to be getting when its value is being retrieved
(e.g. by author script), and is said to be setting when a new value is
assigned to it.
If a DOM object is said to be live, then the attributes and methods on that object
must operate on the actual underlying data, not a snapshot of the
data.
2.1.6 Plugins
The term plugin refers to an implementation-defined set of content
handlers used by the user agent that can take part in the user agent's rendering of a
Document object, but that neither act as child
navigables of the Document nor introduce any Node objects to the
Document's DOM.
Typically such content handlers are provided by third parties, though a user agent can also
designate built-in content handlers as plugins.
A user agent must not consider the types text/plain and
application/octet-stream as having a registered plugin.
One example of a plugin would be a PDF viewer that is instantiated in a
navigable when the user navigates to a PDF file. This would count as a plugin
regardless of whether the party that implemented the PDF viewer component was the same as that
which implemented the user agent itself. However, a PDF viewer application that launches separate
from the user agent (as opposed to using the same interface) is not a plugin by this
definition.
This specification does not define a mechanism for interacting with plugins, as it
is expected to be user-agent- and platform-specific. Some UAs might opt to support a plugin
mechanism such as the Netscape Plugin API; others might use remote content converters or have
built-in support for certain types. Indeed, this specification doesn't require user agents to
support plugins at all. [NPAPI]
Browsers should take extreme care when interacting with external content
intended for plugins. When third-party software is run with the same
privileges as the user agent itself, vulnerabilities in the third-party software become as
dangerous as those in the user agent.
Since different users having different sets of plugins provides a
tracking vector that increases the chances of users being uniquely identified, user agents are
encouraged to support the exact same set of plugins for each
user.
2.1.7 Character encodings
A character
encoding, or just encoding where that is not ambiguous, is a defined way to convert
between byte streams and Unicode strings, as defined in Encoding. An
encoding has an encoding
name and one or more encoding labels, referred to as the
encoding's name and labels in the Encoding standard. [ENCODING]
2.1.8 Conformance classes
This specification describes the conformance criteria for user agents
(relevant to implementers) and documents (relevant to authors and
authoring tool implementers).
Conforming documents are those that comply with all the conformance criteria for
documents. For readability, some of these conformance requirements are phrased as conformance
requirements on authors; such requirements are implicitly requirements on documents: by
definition, all documents are assumed to have had an author. (In some cases, that author may
itself be a user agent — such user agents are subject to additional rules, as explained
below.)
For example, if a requirement states that "authors must not
use the foobar element", it would imply that documents are not allowed to
contain elements named foobar.
There is no implied relationship between document conformance requirements
and implementation conformance requirements. User agents are not free to handle non-conformant
documents as they please; the processing model described in this specification applies to
implementations regardless of the conformity of the input documents.
User agents fall into several (overlapping) categories with different conformance
requirements.
- Web browsers and other interactive user agents
-
Web browsers that support the XML syntax must process elements and attributes
from the HTML namespace found in XML documents as described in this specification,
so that users can interact with them, unless the semantics of those elements have been
overridden by other specifications.
A conforming web browser would, upon finding a script element in
an XML document, execute the script contained in that element. However, if the element is found
within a transformation expressed in XSLT (assuming the user agent also supports XSLT), then the
processor would instead treat the script element as an opaque element that forms
part of the transform.
Web browsers that support the HTML syntax must process documents labeled with an
HTML MIME type as described in this specification, so that users can interact with
them.
User agents that support scripting must also be conforming implementations of the IDL
fragments in this specification, as described in Web IDL. [WEBIDL]
Unless explicitly stated, specifications that override the semantics of HTML
elements do not override the requirements on DOM objects representing those elements. For
example, the script element in the example above would still implement the
HTMLScriptElement interface.
- Non-interactive presentation user agents
-
User agents that process HTML and XML documents purely to render non-interactive versions of
them must comply to the same conformance criteria as web browsers, except that they are exempt
from requirements regarding user interaction.
Typical examples of non-interactive presentation user agents are printers
(static UAs) and overhead displays (dynamic UAs). It is expected that most static
non-interactive presentation user agents will also opt to lack scripting
support.
A non-interactive but dynamic presentation UA would still execute scripts,
allowing forms to be dynamically submitted, and so forth. However, since the concept of "focus"
is irrelevant when the user cannot interact with the document, the UA would not need to support
any of the focus-related DOM APIs.
- Visual user agents that support the suggested default rendering
-
User agents, whether interactive or not, may be designated (possibly as a user option) as
supporting the suggested default rendering defined by this specification.
This is not required. In particular, even user agents that do implement the suggested default
rendering are encouraged to offer settings that override this default to improve the experience
for the user, e.g. changing the color contrast, using different focus styles, or otherwise
making the experience more accessible and usable to the user.
User agents that are designated as supporting the suggested default rendering must, while so
designated, implement the rules the Rendering section defines as the
behavior that user agents are expected to implement.
- User agents with no scripting support
-
Implementations that do not support scripting (or which have their scripting features
disabled entirely) are exempt from supporting the events and DOM interfaces mentioned in this
specification. For the parts of this specification that are defined in terms of an events model
or in terms of the DOM, such user agents must still act as if events and the DOM were
supported.
Scripting can form an integral part of an application. Web browsers that do not
support scripting, or that have scripting disabled, might be unable to fully convey the author's
intent.
- Conformance checkers
-
Conformance checkers must verify that a document conforms to the applicable conformance
criteria described in this specification. Automated conformance checkers are exempt from
detecting errors that require interpretation of the author's intent (for example, while a
document is non-conforming if the content of a blockquote element is not a quote,
conformance checkers running without the input of human judgement do not have to check that
blockquote elements only contain quoted material).
Conformance checkers must check that the input document conforms when parsed without a
browsing context (meaning that no scripts are run, and
that the parser's scripting is disabled), and
should also check that the input document conforms when parsed with a browsing context in which scripts execute, and that the
scripts never cause non-conforming states to occur other than transiently during script
execution itself. (This is only a "SHOULD" and not a "MUST" requirement because it has been
proven to be impossible. [COMPUTABLE])
The term "HTML validator" can be used to refer to a conformance checker that itself conforms
to the applicable requirements of this specification.
XML DTDs cannot express all the conformance requirements of this specification. Therefore, a
validating XML processor and a DTD cannot constitute a conformance checker. Also, since neither
of the two authoring formats defined in this specification are applications of SGML, a
validating SGML system cannot constitute a conformance checker either.
To put it another way, there are three types of conformance criteria:
- Criteria that can be expressed in a DTD.
- Criteria that cannot be expressed by a DTD, but can still be checked by a machine.
- Criteria that can only be checked by a human.
A conformance checker must check for the first two. A simple DTD-based validator only checks
for the first class of errors and is therefore not a conforming conformance checker according
to this specification.
- Data mining tools
-
Applications and tools that process HTML and XML documents for reasons other than to either
render the documents or check them for conformance should act in accordance with the semantics
of the documents that they process.
A tool that generates document outlines but
increases the nesting level for each paragraph and does not increase the nesting level for
headings would not be conforming.
- Authoring tools and markup generators
-
Authoring tools and markup generators must generate conforming documents.
Conformance criteria that apply to authors also apply to authoring tools, where appropriate.
Authoring tools are exempt from the strict requirements of using elements only for their
specified purpose, but only to the extent that authoring tools are not yet able to determine
author intent. However, authoring tools must not automatically misuse elements or encourage
their users to do so.
For example, it is not conforming to use an address element for
arbitrary contact information; that element can only be used for marking up contact information
for its nearest article or body element ancestor. However, since an
authoring tool is likely unable to determine the difference, an authoring tool is exempt from
that requirement. This does not mean, though, that authoring tools can use address
elements for any block of italics text (for instance); it just means that the authoring tool
doesn't have to verify that when the user uses a tool for inserting contact information for an
article element, that the user really is doing that and not inserting something
else instead.
In terms of conformance checking, an editor has to output documents that conform
to the same extent that a conformance checker will verify.
When an authoring tool is used to edit a non-conforming document, it may preserve the
conformance errors in sections of the document that were not edited during the editing session
(i.e., an editing tool is allowed to roundtrip erroneous content). However, an authoring tool
must not claim that the output is conformant if errors have been so preserved.
Authoring tools are expected to come in two broad varieties: tools that work from structure
or semantic data, and tools that work on a What-You-See-Is-What-You-Get media-specific editing
basis (WYSIWYG).
The former is the preferred mechanism for tools that author HTML, since the structure in the
source information can be used to make informed choices regarding which HTML elements and
attributes are most appropriate.
However, WYSIWYG tools are legitimate. WYSIWYG tools should use elements they know are
appropriate, and should not use elements that they do not know to be appropriate. This might in
certain extreme cases mean limiting the use of flow elements to just a few elements, like
div, b, i, and span and making liberal use
of the style attribute.
All authoring tools, whether WYSIWYG or not, should make a best effort attempt at enabling
users to create well-structured, semantically rich, media-independent content.
For compatibility with existing content and prior specifications, this specification describes
two authoring formats: one based on XML, and one using a custom format inspired by SGML (referred to as the HTML syntax).
Implementations must support at least one of these two formats, although supporting both is
encouraged.
Some conformance requirements are phrased as requirements on elements, attributes, methods or
objects. Such requirements fall into two categories: those describing content model restrictions,
and those describing implementation behavior. Those in the former category are requirements on
documents and authoring tools. Those in the second category are requirements on user agents.
Similarly, some conformance requirements are phrased as requirements on authors; such requirements
are to be interpreted as conformance requirements on the documents that authors produce. (In other
words, this specification does not distinguish between conformance criteria on authors and
conformance criteria on documents.)
2.1.9 Dependencies
This specification relies on several other underlying specifications.
- Infra
-
The following terms are defined in Infra: [INFRA]
- The general iteration terms while,
continue, and
break.
- Assert
- implementation-defined
- willful violation
-
tracking vector - code point and its synonym
character
- surrogate
- scalar value
- tuple
- noncharacter
- string,
code unit,
code unit prefix,
code unit less than,
starts with,
ends with,
length, and
code point length
- The string equality operations is and
identical to
- The equality of a data type,
equals, and
itemwise equality
- scalar value string
- convert
- ASCII string
- ASCII tab or newline
- ASCII whitespace
- control
- ASCII digit
- ASCII upper hex digit
- ASCII lower hex digit
- ASCII hex digit
- ASCII upper alpha
- ASCII lower alpha
- ASCII alpha
- ASCII alphanumeric
- isomorphic decode
- isomorphic encode
- ASCII lowercase
- ASCII uppercase
- ASCII case-insensitive
- strip newlines
- normalize newlines
- strip leading and trailing ASCII whitespace
- strip and collapse ASCII whitespace
- split a string on ASCII whitespace
- split a string on commas
- collect a sequence of code points and its associated
position variable
- skip ASCII whitespace
- The ordered map data structure and the associated definitions for
key,
value,
empty,
entry,
exists,
getting the value of an entry,
setting the value of an entry,
with default,
removing an entry,
clear,
getting the keys,
getting the values,
sorting in descending order,
size,
clone, and
iterate
- The list data structure and the associated definitions for
append,
extend,
has duplicates,
prepend,
replace,
remove,
empty,
contains,
size,
indices,
is empty,
item,
iterate,
clone,
sort in ascending order,
sort in descending order,
slice (and its
from and
to arguments), and
reverse
- The stack data structure and the associated definitions for
push and
pop
- The queue data structure and the associated definitions for
enqueue and
dequeue
- The ordered set data structure and the associated definition for
append,
create,
difference,
intersection,
subset and
union
- The struct specification type and the associated definition for
item
- The byte sequence data structure
- The allowed and
blocked singletons
- The forgiving-base64 encode and
forgiving-base64 decode algorithms
- exclusive range
- parse a JSON string to an Infra value
- HTML namespace
- MathML namespace
- SVG namespace
- XLink namespace
- XML namespace
- XMLNS namespace
- success
- Unicode and Encoding
-
The Unicode character set is used to represent textual data, and Encoding
defines requirements around character encodings.
[UNICODE]
This specification introduces terminology
based on the terms defined in those specifications, as described earlier.
The following terms are used as defined in Encoding: [ENCODING]
- Getting an
encoding
- Get an output
encoding
- The generic decode
algorithm which takes a byte stream and an encoding and returns a character stream
- The UTF-8 decode
algorithm which takes a byte stream and returns a character stream, additionally stripping one
leading UTF-8 Byte Order Mark (BOM), if any
- The UTF-8
decode without BOM algorithm which is identical to UTF-8 decode except that
it does not strip one leading UTF-8 Byte Order Mark (BOM)
- The encode algorithm
which takes a character stream and an encoding and returns a byte stream
- The UTF-8 encode
algorithm which takes a character stream and returns a byte stream
- The BOM sniff
algorithm which takes a byte stream and returns an encoding or null.
- XML and related specifications
-
Implementations that support the XML syntax for HTML must support some version
of XML, as well as its corresponding namespaces specification, because that syntax uses an XML
serialization with namespaces. [XML] [XMLNS]
Data mining tools and other user agents that perform operations on content without running
scripts, evaluating CSS or XPath expressions, or otherwise exposing the resulting DOM to
arbitrary content, may "support namespaces" by just asserting that their DOM node analogues are
in certain namespaces, without actually exposing the namespace strings.
In the HTML syntax, namespace prefixes and namespace declarations
do not have the same effect as in XML. For instance, the colon has no special meaning in HTML
element names.
The attribute with the name space in the XML namespace is defined by
Extensible Markup Language (XML). [XML]
The Name production is defined in XML.
[XML]
This specification also references the <?xml-stylesheet?>
processing instruction, defined in Associating Style Sheets with XML documents.
[XMLSSPI]
This specification also non-normatively mentions the XSLTProcessor
interface and its transformToFragment() and transformToDocument() methods.
[XSLTP]
- URLs
-
The following terms are defined in URL: [URL]
A number of schemes and protocols are referenced by this specification also:
Media fragment
syntax is defined in Media Fragments URI. [MEDIAFRAG]
- URL Pattern
-
The following terms are defined in URL Pattern: [URLPATTERN]
- HTTP and related specifications
-
The following terms are defined in the HTTP specifications: [HTTP]
The following terms are defined in HTTP State Management Mechanism:
[COOKIES]
The following term is defined in Web Linking: [WEBLINK]
The following terms are defined in Structured Field Values for HTTP:
[STRUCTURED-FIELDS]
The following terms are defined in MIME Sniffing: [MIMESNIFF]
- Fetch
-
The following terms are defined in Fetch: [FETCH]
The following terms are defined in Referrer Policy:
[REFERRERPOLICY]
The following terms are defined in Mixed Content: [MIX]
The following terms are defined in Subresource Integrity: [SRI]
- Streams
-
The following terms are defined in Streams: [STREAMS]
- The No-Vary-Search HTTP Response Header Field
-
The following terms are defined in The No-Vary-Search HTTP Response Header
Field: [NOVARYSEARCH]
- Paint Timing
-
The following terms are defined in Paint Timing: [PAINTTIMING]
- Navigation Timing
-
The following terms are defined in Navigation Timing:
[NAVIGATIONTIMING]
- Resource Timing
-
The following terms are defined in Resource Timing:
[RESOURCETIMING]
- Performance Timeline
-
The following terms are defined in Performance Timeline:
[PERFORMANCETIMELINE]
- Long Animation Frames
-
The following terms are defined in Long Animation Frames: [LONGANIMATIONFRAMES]
- Long Tasks
-
The following terms are defined in Long Tasks: [LONGTASKS]
- Web IDL
-
The IDL fragments in this specification must be interpreted as required for conforming IDL
fragments, as described in Web IDL. [WEBIDL]
The following terms are defined in Web IDL:
Web IDL also defines the following types that are used in this specification:
The term throw in this
specification is used as defined in Web IDL. The DOMException
type and the following exception names are defined by Web IDL and used by this
specification:
When this specification requires a user agent to create a Date object
representing a particular time (which could be the special value Not-a-Number), the milliseconds
component of that time, if any, must be truncated to an integer, and the time value of the newly
created Date object must represent the resulting truncated time.
For instance, given the time 23045 millionths of a second after 00:00 UTC on
January 1st 2000, i.e. the time 2000-01-01T00:00:00.023045Z, then the Date object
created representing that time would represent the same time as that created representing the
time 2000-01-01T00:00:00.023Z, 45 millionths earlier. If the given time is NaN, then the result
is a Date object that represents a time value NaN (indicating that the object does
not represent a specific instant of time).
- JavaScript
-
Some parts of the language described by this specification only support JavaScript as the
underlying scripting language. [JAVASCRIPT]
The term "JavaScript" is used to refer to ECMA-262, rather than the official
term ECMAScript, since the term JavaScript is more widely known.
The following terms are defined in the JavaScript specification and used in this
specification:
- active function object
- agent and
agent cluster
- automatic semicolon insertion
- candidate execution
- The current realm
- clamping a mathematical value
- early error
- forward progress
- invariants of the essential internal methods
- JavaScript execution context
- JavaScript execution context stack
- realm
- JobCallback Record
- NewTarget
- running JavaScript execution context
- surrounding agent
- abstract closure
- immutable prototype exotic object
- Well-Known Symbols, including
%Symbol.hasInstance%,
%Symbol.isConcatSpreadable%,
%Symbol.toPrimitive%, and
%Symbol.toStringTag%
- Well-Known Intrinsic Objects, including
%Array.prototype%,
%Error.prototype%,
%EvalError.prototype%,
%Function.prototype%,
%Object.prototype%,
%Object.prototype.valueOf%,
%RangeError.prototype%,
%ReferenceError.prototype%,
%SyntaxError.prototype%,
%TypeError.prototype%, and
%URIError.prototype%
- The FunctionBody production
- The Module production
- The Pattern production
- The Script production
- The
BigInt,
Boolean,
Number,
String,
Symbol,
and Object ECMAScript language types
- The Completion Record specification type
- The List and
Record specification types
- The Property Descriptor specification type
- The ModuleRequest Record specification type
- The Script Record specification type
- The Synthetic Module Record specification type
- The Cyclic Module Record specification type
- The Source Text Module Record specification type and its
Evaluate,
Link and
LoadRequestedModules methods
- The ArrayCreate abstract operation
- The Call abstract operation
- The ClearKeptObjects abstract operation
- The CleanupFinalizationRegistry abstract operation
- The Construct abstract operation
- The CopyDataBlockBytes abstract operation
- The CreateBuiltinFunction abstract operation
- The CreateByteDataBlock abstract operation
- The CreateDataProperty abstract operation
- The CreateDefaultExportSyntheticModule abstract operation
- The DefinePropertyOrThrow abstract operation
- The DetachArrayBuffer abstract operation
- The EnumerableOwnProperties abstract operation
- The FinishLoadingImportedModule abstract operation
- The OrdinaryFunctionCreate abstract operation
- The Get abstract operation
- The GetActiveScriptOrModule abstract operation
- The GetFunctionRealm abstract operation
- The HasOwnProperty abstract operation
- The HostCallJobCallback abstract operation
- The HostEnqueueFinalizationRegistryCleanupJob abstract operation
- The HostEnqueueGenericJob abstract operation
- The HostEnqueuePromiseJob abstract operation
- The HostEnqueueTimeoutJob abstract operation
- The HostEnsureCanAddPrivateElement abstract operation
- The HostGetSupportedImportAttributes abstract operation
- The HostLoadImportedModule abstract operation
- The HostMakeJobCallback abstract operation
- The HostPromiseRejectionTracker abstract operation
- The InitializeHostDefinedRealm abstract operation
- The IsArrayBufferViewOutOfBounds abstract operation
- The IsAccessorDescriptor abstract operation
- The IsCallable abstract operation
- The IsConstructor abstract operation
- The IsDataDescriptor abstract operation
- The IsDetachedBuffer abstract operation
- The IsSharedArrayBuffer abstract operation
- The NewObjectEnvironment abstract operation
- The NormalCompletion abstract operation
- The OrdinaryGetPrototypeOf abstract operation
- The OrdinarySetPrototypeOf abstract operation
- The OrdinaryIsExtensible abstract operation
- The OrdinaryPreventExtensions abstract operation
- The OrdinaryGetOwnProperty abstract operation
- The OrdinaryDefineOwnProperty abstract operation
- The OrdinaryGet abstract operation
- The OrdinarySet abstract operation
- The OrdinaryDelete abstract operation
- The OrdinaryOwnPropertyKeys abstract operation
- The OrdinaryObjectCreate abstract operation
- The ParseJSONModule abstract operation
- The ParseModule abstract operation
- The ParseScript abstract operation
- The NewPromiseReactionJob abstract operation
- The NewPromiseResolveThenableJob abstract operation
- The RegExpBuiltinExec abstract operation
- The RegExpCreate abstract operation
- The RunJobs abstract operation
- The SameValue abstract operation
- The ScriptEvaluation abstract operation
- The SetSyntheticModuleExport abstract operation
- The SetImmutablePrototype abstract operation
- The ThrowCompletion abstract operation
- The ToBoolean abstract operation
- The ToString abstract operation
- The ToUint32 abstract operation
- The TypedArrayCreate abstract operation
- The IsLooselyEqual abstract operation
- The IsStrictlyEqual abstract operation
- The
Atomics object - The
Atomics.waitAsync object - The
Date class - The
FinalizationRegistry class - The
RegExp class - The
SharedArrayBuffer class - The
SyntaxError class - The
TypeError class - The
RangeError class - The
WeakRef class - The
eval() function - The
WeakRef.prototype.deref() function - The [[IsHTMLDDA]] internal slot
import()import.meta- The HostGetImportMetaProperties abstract operation
- The
typeof operator - The
delete operator - The TypedArray Constructors table
User agents that support JavaScript must also implement the Dynamic Code Brand
Checks proposal. The following terms are defined there, and used in this specification:
[JSDYNAMICCODEBRANDCHECKS]
User agents that support JavaScript must also implement the Import Text proposal.
The following term is defined there, and used in this specification: [JSIMPORTTEXT]
User agents that support JavaScript must also implement ECMAScript
Internationalization API. [JSINTL]
User agents that support JavaScript must also implement the Temporal proposal.
The following terms are defined there, and used in this specification: [JSTEMPORAL]
- WebAssembly
-
The following term is defined in WebAssembly JavaScript Interface:
[WASMJS]
- DOM
-
The Document Object Model (DOM) is a representation — a model — of a document and
its content. The DOM is not just an API; the conformance criteria of HTML implementations are
defined, in this specification, in terms of operations on the DOM. [DOM]
Implementations must support DOM and the events defined in UI Events, because this
specification is defined in terms of the DOM, and some of the features are defined as extensions
to the DOM interfaces. [DOM] [UIEVENTS]
In particular, the following features are defined in DOM: [DOM]
Attr interfaceCDATASection interfaceCharacterData interfaceComment interfaceDOMImplementation interfaceDocument interface and its
doctype attribute
DocumentOrShadowRoot interfaceDocumentFragment interfaceDocumentType interfaceChildNode interfaceElement interfaceattachShadow() method.- An element's shadow root
- A shadow root's mode
- A shadow root's declarative member
- The attach a shadow root algorithm
- The retargeting algorithm
Node interfaceNodeList interfaceNonDocumentTypeChildNode interfaceProcessingInstruction interface, its
target concept, and the
get a processing instruction attribute algorithmShadowRoot interfaceText interfaceRange interface- node document concept
- document type concept
- host concept
- The shadow root concept, and its delegates focus, available to element internals, serializable, clonable, custom element registry, and keep custom element registry null.
- The shadow host concept
HTMLCollection interface, its
length attribute, and its
item() and
namedItem() methods- The terms collection and represented by the collection
DOMTokenList interface, and its
value attribute and
supports operationcreateDocument() methodcreateHTMLDocument() methodcreateElement() methodcreateElementNS() methodgetElementById() methodgetElementsByClassName() methodappend() methodappendChild() methodcloneNode() methodmoveBefore() methodimportNode() methodpreventDefault() methodid attributesetAttribute() methodbefore() methodtextContent attributechildren attribute- The tree, shadow tree, and node tree concepts
- The tree order and shadow-including tree order concepts
- The element concept
- The child concept
- The root and shadow-including root concepts
- The inclusive ancestor,
ancestor,
descendant,
shadow-including ancestor,
shadow-including descendant,
shadow-including inclusive descendant,
shadow-including inclusive ancestor, and
host-including inclusive ancestor concepts
- The first child,
last child,
next sibling,
previous sibling, and
parent concepts
- The parent element concept
- The document element concept
- The in a document tree, in a document (legacy), and connected concepts
- The slot concept, and its name and assigned nodes
- The assigned slot concept
- The slot assignment concept
- The slottable concept
- The assign slottables for a tree algorithm
- The
slotchange event - The inclusive descendant concept
- The find flattened slottables algorithm
- The manual slot assignment concept
- The assign a slot algorithm
- The pre-insert, ensure pre-insert validity, insert, append, replace, replace all, string replace all, remove, and adopt algorithms for nodes
- The insertion steps,
- The post-connection steps,
removing steps,
moving steps,
adopting steps, and
children changed steps hooks for elements
- The change, append, remove, replace, get an attribute by namespace and local name, set value, and remove an attribute by namespace and local name algorithms for attributes
- The attribute change steps hook for attributes
- The value concept for attributes
- The local name concept for attributes
- The namespace concept for attributes
- The attribute list concept
- The data of a
CharacterData node and its
replace data algorithm - The child text content of a node
- The descendant text content of a node
- The name,
public ID, and
system ID of a doctype
Event interfaceEvent and derived interfaces constructor behaviorEventTarget interface- The activation behavior hook
- The legacy-pre-activation behavior hook
- The legacy-canceled-activation behavior hook
- The create an event algorithm
- The fire an event algorithm
- The canceled flag
- The dispatch flag
- The dispatch algorithm
EventInit dictionary typetype attribute- An event's target
currentTarget attributebubbles attributecancelable attributecomposed attribute- composed flag
isTrusted attributeinitEvent() method- add an event listener
addEventListener() method- The remove an event listener and
remove all event listeners algorithms
EventListener callback interface- The type of an event
- An event listener and its
type and
callback
- The encoding (herein the character encoding),
mode,
custom element registry,
allow declarative shadow roots, and
content type of a
Document - The get the base URL algorithm and
base URL override of a
Document - The distinction between XML documents and
HTML documents
- The terms quirks mode,
limited-quirks mode, and
no-quirks mode
- The algorithm clone a node with its arguments
document,
subtree,
parent, and
fallbackRegistry, and the concept of
cloning steps
- The concept of an element's unique identifier (ID)
- The concept of an element's classes
- The term supported tokens
- The concept of a DOM range, and the terms
start node,
start,
end, and
boundary point as applied to ranges.
- The create an element algorithm
- The create a document,
create a text node,
create a CDATA section node,
create a doctype,
create a comment node,
create a processing instruction node, and
create a document fragment algorithms
- The element interface concept
- The concepts of custom element state, and of
defined and
custom elements
- An element's namespace,
namespace prefix,
local name,
custom element registry,
custom element definition, and
is value MutationObserver interface and mutation observers in generalAbortController and its
signalAbortSignal- aborted
- signal abort
- add
- valid attribute local name
- valid element local name
- is a global custom element registry
- The get text content and
set text content algorithms
The following features are defined in UI Events: [UIEVENTS]
The following features are defined in Touch Events: [TOUCH]
The following features are defined in Pointer Events:
[POINTEREVENTS]
The following events are defined in Clipboard API and events:
[CLIPBOARD-APIS]
This specification sometimes uses the term name to refer to the event's
type; as in, "an event named click" or "if the event name is keypress". The terms
"name" and "type" for events are synonymous.
The following features are defined in DOM Parsing and Serialization:
[DOMPARSING]
The following features are defined in Selection API: [SELECTION]
User agents are encouraged to implement the features described in
execCommand. [EXECCOMMAND]
The following features are defined in Fullscreen API: [FULLSCREEN]
High Resolution Time provides the following features: [HRT]
- File API
-
This specification uses the following features defined in File API:
[FILEAPI]
- Indexed Database API
-
The following terms are defined in Indexed Database API:
[INDEXEDDB]
- Media Source Extensions
-
The following terms are defined in Media Source Extensions:
[MEDIASOURCE]
- Media Capture and Streams
-
The following terms are defined in Media Capture and Streams:
[MEDIASTREAM]
- Reporting
-
The following terms are defined in Reporting: [REPORTING]
- XMLHttpRequest
-
The following features and terms are defined in XMLHttpRequest:
[XHR]
- Battery Status
-
The following features are defined in Battery Status API: [BATTERY]
- Media Queries
-
Implementations must support Media Queries. The <media-condition>
feature is defined therein. [MQ]
- CSS modules
-
While support for CSS as a whole is not required of implementations of this specification
(though it is encouraged, at least for web browsers), some features are defined in terms of
specific CSS requirements.
When this specification requires that something be parsed according
to a particular CSS grammar, the relevant algorithm in CSS Syntax must be
followed, including error handling rules. [CSSSYNTAX]
For example, user agents are required to close all open constructs upon
finding the end of a style sheet unexpectedly. Thus, when parsing the string "rgb(0,0,0" (with a missing close-parenthesis) for a color value, the close
parenthesis is implied by this error handling rule, and a value is obtained (the color 'black').
However, the similar construct "rgb(0,0," (with both a missing
parenthesis and a missing "blue" value) cannot be parsed, as closing the open construct does not
result in a viable value.
The following terms and features are defined in Cascading Style Sheets
(CSS): [CSS]
The basic version of the 'display' property
is defined in CSS, and the property is extended by other CSS modules.
[CSS] [CSSRUBY] [CSSTABLE]
The following terms and features are defined in CSS Box Model:
[CSSBOX]
The following features are defined in CSS Logical Properties:
[CSSLOGICAL]
- The 'margin-block',
'margin-block-start',
'margin-block-end',
'margin-inline',
'margin-inline-start', and
'margin-inline-end' properties
- The 'padding-block',
'padding-block-start',
'padding-block-end',
'padding-inline',
'padding-inline-start', and
'padding-inline-end' properties
- The 'border-block-width',
'border-block-start-width',
'border-block-end-width',
'border-inline-width',
'border-inline-start-width',
'border-inline-end-width',
'border-block-style',
'border-block-start-style',
'border-block-end-style',
'border-inline-style',
'border-inline-start-style',
'border-inline-end-style',
'border-block-start-color',
'border-block-end-color',
'border-inline-start-color',
'border-inline-end-color',
'border-start-start-radius',
'border-start-end-radius',
'border-end-start-radius', and
'border-end-end-radius'
properties
- The 'block-size' property
- The 'inline-size' property
- The 'inset-block-start' property
- The 'inset-block-end' property
The following terms and features are defined in CSS Color:
[CSSCOLOR]
The following terms and features are defined in CSS Color HDR:
[CSSCOLORHDR]
The following terms are defined in CSS Images: [CSSIMAGES]
The term paint
source is used as defined in CSS Images Level 4
to define the interaction of certain HTML elements with the CSS 'element()' function.
[CSSIMAGES4]
The following features are defined in CSS Backgrounds and Borders:
[CSSBG]
- The 'background-color',
'background-image',
'background-repeat',
'background-attachment',
'background-position',
'background-clip',
'background-origin', and
'background-size'
properties
- The 'border-radius',
'border-top-left-radius',
'border-top-right-radius',
'border-bottom-right-radius',
'border-bottom-left-radius'
properties
- The 'border-image-source',
'border-image-slice',
'border-image-width',
'border-image-outset', and
'border-image-repeat'
properties
CSS Backgrounds and Borders also defines the following border properties:
[CSSBG]
The following features are defined in CSS Box Alignment: [CSSALIGN]
The following terms and features are defined in CSS Display:
[CSSDISPLAY]
The following features are defined in CSS Flexible Box Layout:
[CSSFLEXBOX]
The following terms and features are defined in CSS Fonts:
[CSSFONTS]
The following features are defined in CSS Forms:
[CSSFORMS]
The following features are defined in CSS Gaps:
[CSSGAPS]
The following features are defined in CSS Grid Layout: [CSSGRID]
The following terms are defined in CSS Inline Layout: [CSSINLINE]
The following terms and features are defined in CSS Box Sizing:
[CSSSIZING]
The following features are defined in CSS Lists and Counters.
[CSSLISTS]
The following features are defined in CSS Overflow. [CSSOVERFLOW]
The following terms and features are defined in CSS Positioned Layout:
[CSSPOSITION]
The following features are defined in CSS Multi-column Layout.
[CSSMULTICOL]
The 'ruby-base'
value of the 'display' property is defined in CSS Ruby Layout.
[CSSRUBY]
The following features are defined in CSS Table: [CSSTABLE]
The following features are defined in CSS Text: [CSSTEXT]
The following features are defined in CSS Writing Modes: [CSSWM]
- The 'direction' property
- The 'unicode-bidi' property
- The 'writing-mode' property
- The block flow direction,
block axis,
inline axis,
block size,
inline size,
block-start,
block-end,
inline-start,
inline-end,
line-left, and
line-right concepts
The following features are defined in CSS Basic User Interface:
[CSSUI]
The algorithm to update
animations and send events is defined in Web Animations.
[WEBANIMATIONS]
Implementations that support scripting must support the CSS Object Model. The following
features and terms are defined in the CSSOM specifications: [CSSOM]
[CSSOMVIEW]
The following features and terms are defined in CSS Syntax:
[CSSSYNTAX]
The following terms are defined in Selectors: [SELECTORS]
The following features are defined in CSS Values and Units:
[CSSVALUES]
The following features are defined in CSS View Transitions:
[CSSVIEWTRANSITIONS]
The term style attribute is
defined in CSS Style Attributes. [CSSATTR]
The following terms are defined in the CSS Cascading and Inheritance:
[CSSCASCADE]
The CanvasRenderingContext2D object's use of fonts depends on the features
described in the CSS Fonts and Font Loading specifications, including
in particular FontFace objects and the font source concept.
[CSSFONTS] [CSSFONTLOAD]
The following interfaces and terms are defined in Geometry Interfaces:
[GEOMETRY]
The following terms are defined in the CSS Scoping: [CSSSCOPING]
The following terms and features are defined in CSS Color Adjustment:
[CSSCOLORADJUST]
The following terms are defined in CSS Pseudo-Elements: [CSSPSEUDO]
The following terms are defined in CSS Containment: [CSSCONTAIN]
The following terms are defined in CSS Anchor Positioning: [CSSANCHOR]
- Intersection Observer
-
The following term is defined in Intersection Observer:
[INTERSECTIONOBSERVER]
- Resize Observer
-
The following terms are defined in Resize Observer:
[RESIZEOBSERVER]
- WebGL
-
The following interfaces are defined in the WebGL specifications: [WEBGL]
- WebGPU
-
The following interfaces are defined in WebGPU: [WEBGPU]
- WebVTT
-
Implementations may support WebVTT as a text track format for subtitles, captions, metadata,
etc., for media resources. [WEBVTT]
The following terms, used in this specification, are defined in WebVTT:
- ARIA
-
The role attribute is defined in
Accessible Rich Internet Applications (ARIA), as are the following
roles: [ARIA]
In addition, the following aria-* content
attributes are defined in ARIA: [ARIA]
Finally, the following terms are defined in ARIA: [ARIA]
- Accessible Name and Description Computation
-
The following term is defined in Accessible Name and Description
Computation: [ACCNAME]
- Content Security Policy
-
The following terms are defined in Content Security Policy: [CSP]
- Service Workers
-
The following terms are defined in Service Workers: [SW]
- Secure Contexts
-
The following algorithms are defined in Secure Contexts:
[SECURE-CONTEXTS]
- Permissions Policy
-
The following terms are defined in Permissions Policy:
[PERMISSIONSPOLICY]
- Payment Request API
-
The following feature is defined in Payment Request API:
[PAYMENTREQUEST]
- MathML
-
While support for MathML as a whole is not required by this specification (though it is
encouraged, at least for web browsers), certain features depend upon small parts of MathML being
implemented. [MATHML]
The following features are defined in Mathematical Markup Language
(MathML):
- SVG
-
While support for SVG as a whole is not required by this specification (though it is
encouraged, at least for web browsers), certain features depend upon parts of SVG being
implemented.
User agents that implement SVG must implement the SVG 2 specification, and not
any earlier revisions.
The following features are defined in the SVG 2 specification:
[SVG]
- Filter Effects
-
The following features are defined in Filter Effects: [FILTERS]
- Compositing
-
The following features are defined in Compositing and Blending:
[COMPOSITE]
- Cooperative Scheduling of Background Tasks
-
The following features are defined in Cooperative Scheduling of Background
Tasks: [REQUESTIDLECALLBACK]
- Screen Orientation
-
The following terms are defined in Screen Orientation:
[SCREENORIENTATION]
- Storage
-
The following terms are defined in Storage: [STORAGE]
- Web App Manifest
-
The following features are defined in Web App Manifest: [MANIFEST]
- WebAssembly JavaScript Interface: ESM Integration
-
The following terms are defined in WebAssembly JavaScript Interface: ESM Integration: [WASMESM]
- WebCodecs
-
The following features are defined in WebCodecs: [WEBCODECS]
- WebDriver
-
The following terms are defined in WebDriver: [WEBDRIVER]
- WebDriver BiDi
-
The following terms are defined in WebDriver BiDi: [WEBDRIVERBIDI]
- Web Cryptography API
-
The following terms are defined in Web Cryptography API:
[WEBCRYPTO]
- WebSockets
-
The following terms are defined in WebSockets: [WEBSOCKETS]
- WebTransport
-
The following terms are defined in WebTransport: [WEBTRANSPORT]
- Web Authentication: An API for accessing Public Key Credentials
-
The following terms are defined in Web Authentication: An API for accessing Public Key
Credentials: [WEBAUTHN]
- Credential Management
-
The following terms are defined in Credential Management: [CREDMAN]
- Console
-
The following terms are defined in Console: [CONSOLE]
- Web Locks API
-
The following terms are defined in Web Locks API: [WEBLOCKS]
- Trusted Types
-
This specification uses the following features defined in Trusted Types:
[TRUSTED-TYPES]
- WebRTC API
-
The following terms are defined in WebRTC API: [WEBRTC]
- Picture-in-Picture API
-
The following terms are defined in Picture-in-Picture API: [PICTUREINPICTURE]
- Idle Detection API
-
The following terms are defined in Idle Detection API:
- Web Speech API
-
The following terms are defined in Web Speech API:
- WebOTP API
-
The following terms are defined in WebOTP API:
- Web Share API
-
The following terms are defined in Web Share API:
- Web Smart Card API
-
The following terms are defined in Web Smart Card API:
- Web Background Synchronization
-
The following terms are defined in Web Background Synchronization:
- Web Periodic Background Synchronization
-
The following terms are defined in Web Periodic Background Synchronization:
- Web Background Fetch
-
The following terms are defined in Background Fetch:
- Keyboard Lock
-
The following terms are defined in Keyboard Lock:
- Web MIDI API
-
The following terms are defined in Web MIDI API:
- Generic Sensor API
-
The following terms are defined in Generic Sensor API:
- WebHID API
-
The following terms are defined in WebHID API:
- WebXR Device API
-
The following terms are defined in WebXR Device API:
This specification does not require support of any particular network protocol, style
sheet language, scripting language, or any of the DOM specifications beyond those required in the
list above. However, the language described by this specification is biased towards CSS as the
styling language, JavaScript as the scripting language, and HTTP as the network protocol, and
several features assume that those languages and protocols are in use.
A user agent that implements the HTTP protocol must implement HTTP State Management
Mechanism (Cookies) as well. [HTTP] [COOKIES]
This specification might have certain additional requirements on character
encodings, image formats, audio formats, and video formats in the respective sections.
2.1.10 Extensibility
Vendor-specific proprietary user agent extensions to this specification are strongly
discouraged. Documents must not use such extensions, as doing so reduces interoperability and
fragments the user base, allowing only users of specific user agents to access the content in
question.
All extensions must be defined so that the use of extensions neither contradicts nor causes the
non-conformance of functionality defined in the specification.
For example, while strongly discouraged from doing so, an implementation could add a new IDL
attribute "typeTime" to a control that returned the time it took the user
to select the current value of a control (say). On the other hand, defining a new control that
appears in a form's elements array would be in violation
of the above requirement, as it would violate the definition of elements given in this specification.
When vendor-neutral extensions to this specification are needed, either this specification can
be updated accordingly, or an extension specification can be written that overrides the
requirements in this specification. When someone applying this specification to their activities
decides that they will recognize the requirements of such an extension specification, it becomes
an applicable specification for the purposes
of conformance requirements in this specification.
Someone could write a specification that defines any arbitrary byte stream as
conforming, and then claim that their random junk is conforming. However, that does not mean that
their random junk actually is conforming for everyone's purposes: if someone else decides that
that specification does not apply to their work, then they can quite legitimately say that the
aforementioned random junk is just that, junk, and not conforming at all. As far as conformance
goes, what matters in a particular community is what that community agrees is
applicable.
User agents must treat elements and attributes that they do not understand as semantically
neutral; leaving them in the DOM (for DOM processors), and styling them according to CSS (for CSS
processors), but not inferring any meaning from them.
When support for a feature is disabled (e.g. as an emergency measure to mitigate a security
problem, or to aid in development, or for performance reasons), user agents must act as if they
had no support for the feature whatsoever, and as if the feature was not mentioned in this
specification. For example, if a particular feature is accessed via an attribute in a Web IDL
interface, the attribute itself would be omitted from the objects that implement that interface
— leaving the attribute on the object but making it return null or throw an exception is
insufficient.
2.1.11 Interactions with XPath and XSLT
Avoid using client-side XSLT in browsers. The browser implementations of XSLT
are highly susceptible to memory safety vulnerabilities, and the web platform has evolved toward
JavaScript as the safe replacement. For these reasons, this feature is in the process of being
removed from the web platform. (This is a long process that takes many years.)
Implementations of XPath 1.0 that operate on HTML
documents parsed or created in the manners described in this specification (e.g. as part of
the document.evaluate() API) must act as if the following edit was applied
to the XPath 1.0 specification.
First, remove this paragraph:
A QName in the node test is expanded
into an expanded-name
using the namespace declarations from the expression context. This is the same way expansion is
done for element type names in start and end-tags except that the default namespace declared with
xmlns is not used: if the QName does not have a prefix, then the
namespace URI is null (this is the same way attribute names are expanded). It is an error if the
QName has a prefix for which there is
no namespace declaration in the expression context.
Then, insert in its place the following:
A QName in the node test is expanded into an expanded-name using the namespace declarations
from the expression context. If the QName has a prefix, then there must be a namespace declaration for this prefix in
the expression context, and the corresponding namespace URI is the one that is
associated with this prefix. It is an error if the QName has a prefix for which there is no
namespace declaration in the expression context.
If the QName has no prefix and the principal node type of the axis is element, then the
default element namespace is used. Otherwise, if the QName has no prefix, the namespace URI is
null. The default element namespace is a member of the context for the XPath expression. The
value of the default element namespace when executing an XPath expression through the DOM3 XPath
API is determined in the following way:
- If the context node is from an HTML DOM, the default element namespace is
"http://www.w3.org/1999/xhtml".
- Otherwise, the default element namespace URI is null.
This is equivalent to adding the default element namespace feature of XPath 2.0
to XPath 1.0, and using the HTML namespace as the default element namespace for HTML documents.
It is motivated by the desire to have implementations be compatible with legacy HTML content
while still supporting the changes that this specification introduces to HTML regarding the
namespace used for HTML elements, and by the desire to use XPath 1.0 rather than XPath 2.0.
This change is a willful violation of the XPath 1.0 specification,
motivated by desire to have implementations be compatible with legacy content while still
supporting the changes that this specification introduces to HTML regarding which namespace is
used for HTML elements. [XPATH10]
XSLT 1.0 processors outputting to a DOM when the output
method is "html" (either explicitly or via the defaulting rule in XSLT 1.0) are affected as
follows:
If the transformation program outputs an element in no namespace, the processor must, prior to
constructing the corresponding DOM element node, change the namespace of the element to the
HTML namespace, ASCII-lowercase the
element's local name, and ASCII-lowercase the
names of any non-namespaced attributes on the element.
This requirement is a willful violation of the XSLT 1.0
specification, required because this specification changes the namespaces and case-sensitivity
rules of HTML in a manner that would otherwise be incompatible with DOM-based XSLT
transformations. (Processors that serialize the output are unaffected.) [XSLT10]
This specification does not specify precisely how XSLT processing interacts with the HTML
parser infrastructure (for example, whether an XSLT processor acts as if it puts any
elements into a stack of open elements). However, XSLT processors must stop
parsing if they successfully complete, and must update the current document
readiness first to "interactive" and then to "complete" if they are aborted.
This specification does not specify how XSLT interacts with the navigation algorithm, how it fits in with the event loop, nor
how error pages are to be handled (e.g. whether XSLT errors are to replace an incremental XSLT
output, or are rendered inline, etc.).
There are also additional non-normative comments regarding the interaction of XSLT
and HTML in the script element section, and of
XSLT, XPath, and HTML in the template element
section.
2.2 Policy-controlled featuresHeaders/Permissions-Policy/document-domain Support in one engine only. Firefox🔰 74+SafariNoChrome🔰 88+ Opera?Edge🔰 88+ Edge (Legacy)?Internet ExplorerNo Firefox Android?Safari iOS?Chrome AndroidNoWebView Android?Samsung Internet?Opera Android?
This document defines the following policy-controlled features:
Headers/Feature-Policy/autoplay Firefox🔰 74+SafariNoChrome64+ Opera?Edge79+ Edge (Legacy)?Internet ExplorerNo Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?Headers/Permissions-Policy/autoplay Support in one engine only. Firefox🔰 74+SafariNoChrome88+ Opera?Edge88+ Edge (Legacy)?Internet ExplorerNo Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?
|