jsPerf.app is an online JavaScript performance benchmark test runner & jsperf.com mirror. It is a complete rewrite in homage to the once excellent jsperf.com now with hopefully a more modern & maintainable codebase.
jsperf.com URLs are mirrored at the same path, e.g:
https://jsperf.com/negative-modulo/2
Can be accessed at:
https://jsperf.app/negative-modulo/2
Testing out the cases from this StackOverflow question:
http://stackoverflow.com/questions/6035348/fastest-selector-method-in-jquery-and-css-id-or-not
<div id="fullContent">
<div class='navbar' style='text-align: center'>
<map id='navbar-top' name='navbar-top' title='Navigation Bar'><p>
[<a title='What is the Document Object Model?' accesskey='p' href='introduction.html'><strong><u>p</u></strong>revious</a>]
[<a title='Changes' accesskey='n' href='changes.html'><strong><u>n</u></strong>ext</a>] [<a title='Table of Contents' accesskey='c' href='Overview.html#contents'><strong><u>c</u></strong>ontents</a>] [<a title='Index'
accesskey='i' href='def-index.html'><strong><u>i</u></strong>ndex</a>]</p>
<hr title='Navigation area separator'>
</map></div>
<div class='noprint' style='text-align: right'>
<p style='font-family: monospace;font-size:small'>07 April 2004</p>
</div>
<div class='div1'><a name='Core'></a>
<h1 id='Core-h1' class='div1'>1.
Document Object Model Core</h1><dl>
<dt><i>Editors</i>:
</dt><dd>Arnaud Le Hors, IBM</dd>
<dd>Philippe Le Hégaret, W3C</dd>
<dd>Gavin Nicol, Inso EPS (for DOM Level 1)</dd>
<dd>Lauren Wood, SoftQuad, Inc. (for DOM Level 1)</dd>
<dd>Mike Champion, Arbortext and Software AG (for DOM Level 1 from November 20,
1997)</dd>
<dd>Steve Byrne, JavaSoft (for DOM Level 1 until November 19,
1997)</dd>
</dl>
<div class='noprint'>
<h2 id='table-of-contents'>Table of contents</h2>
<ul class='toc'>
<li class='tocline3'><a class='tocxref' href='#ID-1590626201'>1.1 Overview of the DOM Core Interfaces</a>
<ul class='toc'>
<li class='tocline4'><a class='tocxref' href='#ID-1590626202'>1.1.1 The DOM Structure Model</a>
<li class='tocline4'><a class='tocxref' href='#ID-249F15BA'>1.1.2 Memory Management</a>
<li class='tocline4'><a class='tocxref' href='#ID-45A944CB'>1.1.3 Naming Conventions</a>
<li class='tocline4'><a class='tocxref' href='#ID-1CED5498'>1.1.4 Inheritance vs. Flattened Views of the API</a>
</ul></li>
<li class='tocline3'><a class='tocxref' href='#BasicTypes'>1.2 Basic Types</a>
<ul class='toc'>
<li class='tocline4'><a class='tocxref' href='#ID-C74D1578'>1.2.1 The DOMString Type</a>
<ul>
<li class='tocline5'><a href='#DOMString'>DOMString</a></ul>
<li class='tocline4'><a class='tocxref' href='#Core-DOMTimeStamp'>1.2.2 The DOMTimeStamp Type</a>
<ul>
<li class='tocline5'><a href='#DOMTimeStamp'>DOMTimeStamp</a></ul>
<li class='tocline4'><a class='tocxref' href='#Core-DOMUserData'>1.2.3 The DOMUserData Type</a>
<ul>
<li class='tocline5'><a href='#DOMUserData'>DOMUserData</a></ul>
<li class='tocline4'><a class='tocxref' href='#Core-DOMObject'>1.2.4 The DOMObject Type</a>
<ul>
<li class='tocline5'><a href='#DOMObject'>DOMObject</a></ul>
</ul></li>
<li class='tocline3'><a class='tocxref' href='#Consideration'>1.3 General Considerations</a>
<ul class='toc'>
<li class='tocline4'><a class='tocxref' href='#ID-5DFED1F0'>1.3.1 String Comparisons in the DOM</a>
<li class='tocline4'><a class='tocxref' href='#domURIs'>1.3.2 DOM URIs</a>
<li class='tocline4'><a class='tocxref' href='#Namespaces-Considerations'>1.3.3 XML Namespaces</a>
<li class='tocline4'><a class='tocxref' href='#baseURIs-Considerations'>1.3.4 Base URIs</a>
<li class='tocline4'><a class='tocxref' href='#Embedded-DOM'>1.3.5 Mixed DOM Implementations</a>
<li class='tocline4'><a class='tocxref' href='#DOMFeatures'>1.3.6 DOM Features</a>
<li class='tocline4'><a class='tocxref' href='#Bootstrap'>1.3.7 Bootstrapping</a>
</ul></li>
<li class='tocline3'><a class='tocxref' href='#ID-BBACDC08'>1.4 Fundamental Interfaces: Core Module</a>
<ul class='toc'>
<li class='tocline4'><a href='#ID-17189187'>DOMException</a>,
<a href='#ID-258A00AF'>ExceptionCode</a>,
<a href='#DOMStringList'>DOMStringList</a>,
<a href='#NameList'>NameList</a>,
<a href='#DOMImplementationList'>DOMImplementationList</a>,
<a href='#DOMImplementationSource'>DOMImplementationSource</a>,
<a href='#ID-102161490'>DOMImplementation</a>,
<a href='#ID-B63ED1A3'>DocumentFragment</a>,
<a href='#i-Document'>Document</a>,
<a href='#ID-1950641247'>Node</a>,
<a href='#ID-536297177'>NodeList</a>,
<a href='#ID-1780488922'>NamedNodeMap</a>,
<a href='#ID-FF21A306'>CharacterData</a>,
<a href='#ID-637646024'>Attr</a>,
<a href='#ID-745549614'>Element</a>,
<a href='#ID-1312295772'>Text</a>,
<a href='#ID-1728279322'>Comment</a>,
<a href='#TypeInfo'>TypeInfo</a>,
<a href='#UserDataHandler'>UserDataHandler</a>,
<a href='#ERROR-Interfaces-DOMError'>DOMError</a>,
<a href='#ERROR-Interfaces-DOMErrorHandler'>DOMErrorHandler</a>,
<a href='#Interfaces-DOMLocator'>DOMLocator</a>,
<a href='#DOMConfiguration'>DOMConfiguration</a></ul></li>
<li class='tocline3'><a class='tocxref' href='#ID-E067D597'>1.5 Extended Interfaces: XML Module</a>
<ul class='toc'>
<li class='tocline4'><a href='#ID-667469212'>CDATASection</a>,
<a href='#ID-412266927'>DocumentType</a>,
<a href='#ID-5431D1B9'>Notation</a>,
<a href='#ID-527DCFF2'>Entity</a>,
<a href='#ID-11C98490'>EntityReference</a>,
<a href='#ID-1004215813'>ProcessingInstruction</a></ul></li>
</ul>
</div>
<p class='first'>
This specification defines a set of objects and interfaces for
accessing and manipulating document objects. The functionality
specified (the <em>Core</em> functionality) is sufficient to
allow software developers and Web script authors to access and
manipulate parsed HTML [<cite><a class='noxref informative' href='references.html#HTML40'>HTML 4.01</a></cite>] and
XML [<cite><a class='noxref informative' href='references.html#XML'>XML 1.0</a></cite>] content inside conforming
products. The DOM Core <a href='glossary.html#dt-API'>API</a> also
allows creation and population of a <a href='core.html#i-Document'><code>Document</code></a> object
using only DOM API calls. A solution for loading a
<a class='noxref' href='core.html#i-Document'><code>Document</code></a> and saving it persistently is proposed in
[<cite><a class='noxref informative' href='references.html#DOMLS'>DOM Level 3 Load and Save</a></cite>].
</p>
<div class='div2'><a name='ID-1590626201'></a>
<h2 id='ID-1590626201-h2' class='div2'>1.1
Overview of the DOM Core Interfaces</h2>
<div class='div3'><a name='ID-1590626202'></a>
<h3 id='ID-1590626202-h3' class='div3'>1.1.1
The DOM Structure Model</h3><p>The DOM presents documents as a hierarchy of <a href='core.html#ID-1950641247'><code>Node</code></a> objects
that also implement other, more specialized interfaces. Some types of
nodes may have <a href='glossary.html#dt-child'>child</a> nodes of various
types, and others are leaf nodes that cannot have anything below them
in the document structure. For XML and HTML, the node types, and which
node types they may have as children, are as follows:
<ul>
<li>
<a href='core.html#i-Document'><code>Document</code></a> -- <a href='core.html#ID-745549614'><code>Element</code></a> (maximum of one),
<a href='core.html#ID-1004215813'><code>ProcessingInstruction</code></a>, <a href='core.html#ID-1728279322'><code>Comment</code></a>,
<a href='core.html#ID-412266927'><code>DocumentType</code></a> (maximum of one) </li>
<li>
<a href='core.html#ID-B63ED1A3'><code>DocumentFragment</code></a> -- <a href='core.html#ID-745549614'><code>Element</code></a>,
<a href='core.html#ID-1004215813'><code>ProcessingInstruction</code></a>, <a href='core.html#ID-1728279322'><code>Comment</code></a>,
<a href='core.html#ID-1312295772'><code>Text</code></a>, <a href='core.html#ID-667469212'><code>CDATASection</code></a>,
<a href='core.html#ID-11C98490'><code>EntityReference</code></a> </li>
<li>
<a href='core.html#ID-412266927'><code>DocumentType</code></a> -- no children</li>
<li>
<a href='core.html#ID-11C98490'><code>EntityReference</code></a> -- <a href='core.html#ID-745549614'><code>Element</code></a>,
<a href='core.html#ID-1004215813'><code>ProcessingInstruction</code></a>, <a href='core.html#ID-1728279322'><code>Comment</code></a>,
<a href='core.html#ID-1312295772'><code>Text</code></a>, <a href='core.html#ID-667469212'><code>CDATASection</code></a>,
<a class='noxref' href='core.html#ID-11C98490'><code>EntityReference</code></a> </li>
<li>
<a href='core.html#ID-745549614'><code>Element</code></a> -- <a class='noxref' href='core.html#ID-745549614'><code>Element</code></a>, <a href='core.html#ID-1312295772'><code>Text</code></a>,
<a href='core.html#ID-1728279322'><code>Comment</code></a>, <a href='core.html#ID-1004215813'><code>ProcessingInstruction</code></a>,
<a href='core.html#ID-667469212'><code>CDATASection</code></a>, <a href='core.html#ID-11C98490'><code>EntityReference</code></a></li>
<li>
<a href='core.html#ID-637646024'><code>Attr</code></a> -- <a href='core.html#ID-1312295772'><code>Text</code></a>,
<a href='core.html#ID-11C98490'><code>EntityReference</code></a></li>
<li>
<a href='core.html#ID-1004215813'><code>ProcessingInstruction</code></a> -- no children</li>
<li>
<a href='core.html#ID-1728279322'><code>Comment</code></a> -- no children</li>
<li>
<a href='core.html#ID-1312295772'><code>Text</code></a> -- no children</li>
<li>
<a href='core.html#ID-667469212'><code>CDATASection</code></a> -- no children</li>
<li>
<a href='core.html#ID-527DCFF2'><code>Entity</code></a> -- <a href='core.html#ID-745549614'><code>Element</code></a>,
<a href='core.html#ID-1004215813'><code>ProcessingInstruction</code></a>, <a href='core.html#ID-1728279322'><code>Comment</code></a>,
<a href='core.html#ID-1312295772'><code>Text</code></a>, <a href='core.html#ID-667469212'><code>CDATASection</code></a>,
<a href='core.html#ID-11C98490'><code>EntityReference</code></a></li>
<li>
<a href='core.html#ID-5431D1B9'><code>Notation</code></a> -- no children</li>
</ul>
<p>The DOM also specifies a <a href='core.html#ID-536297177'><code>NodeList</code></a> interface to handle
ordered lists of <a href='core.html#ID-1950641247'><code>Nodes</code></a>, such as the children of a
<a href='core.html#ID-1950641247'><code>Node</code></a>, or the <a href='glossary.html#dt-element'>elements</a>
returned by the
<a href='core.html#ID-A6C90942'><code>Element.getElementsByTagNameNS(namespaceURI, localName)</code></a> method, and also a <a href='core.html#ID-1780488922'><code>NamedNodeMap</code></a>
interface to handle unordered sets of nodes referenced by their name
attribute, such as the attributes of an <a href='core.html#ID-745549614'><code>Element</code></a>.
<a name='td-live'></a> <a href='core.html#ID-536297177'><code>NodeList</code></a> and
<a href='core.html#ID-1780488922'><code>NamedNodeMap</code></a> objects in the DOM are <i>live</i>;
that is, changes to the underlying document structure are reflected
in all relevant <a class='noxref' href='core.html#ID-536297177'><code>NodeList</code></a> and <a class='noxref' href='core.html#ID-1780488922'><code>NamedNodeMap</code></a>
objects. For example, if a DOM user gets a <a class='noxref' href='core.html#ID-536297177'><code>NodeList</code></a>
object containing the children of an <a href='core.html#ID-745549614'><code>Element</code></a>, then
subsequently adds more children to that
<a href='glossary.html#dt-element'>element</a> (or removes children, or
modifies them), those changes are automatically reflected in the
<a class='noxref' href='core.html#ID-536297177'><code>NodeList</code></a>, without further action on the user's
part. Likewise, changes to a <a href='core.html#ID-1950641247'><code>Node</code></a> in the tree are
reflected in all references to that <a class='noxref' href='core.html#ID-1950641247'><code>Node</code></a> in
<a class='noxref' href='core.html#ID-536297177'><code>NodeList</code></a> and <a class='noxref' href='core.html#ID-1780488922'><code>NamedNodeMap</code></a>
objects.<p>Finally, the interfaces <a href='core.html#ID-1312295772'><code>Text</code></a>,
<a href='core.html#ID-1728279322'><code>Comment</code></a>, and <a href='core.html#ID-667469212'><code>CDATASection</code></a> all inherit from
the <a href='core.html#ID-FF21A306'><code>CharacterData</code></a> interface.</div> <!-- div3 ID-1590626202 -->
<div class='div3'><a name='ID-249F15BA'></a>
<h3 id='ID-249F15BA-h3' class='div3'>1.1.2
Memory Management</h3><p>Most of the APIs defined by this specification are
<em>interfaces</em> rather than classes. That means that an
implementation need only expose methods with the defined names and
specified operation, not implement classes that correspond directly to
the interfaces. This allows the DOM APIs to be implemented as a thin
veneer on top of legacy applications with their own data structures, or
on top of newer applications with different class hierarchies. This
also means that ordinary constructors (in the Java or C++ sense) cannot
be used to create DOM objects, since the underlying objects to be
constructed may have little relationship to the DOM interfaces. The
conventional solution to this in object-oriented design is to define
<em>factory</em> methods that create instances of objects that
implement the various interfaces. Objects implementing some interface
"X" are created by a "createX()" method on the <a href='core.html#i-Document'><code>Document</code></a>
interface; this is because all DOM objects live in the context of a
specific Document.<p>The Core DOM APIs are designed to be compatible with a wide range of
languages, including both general-user scripting languages and the more
challenging languages used mostly by professional programmers. Thus,
the DOM APIs need to operate across a variety of memory management
philosophies, from language bindings that do not expose memory
management to the user at all, through those (notably Java) that
provide explicit constructors but provide an automatic garbage
collection mechanism to automatically reclaim unused memory, to those
(especially C/C++) that generally require the programmer to explicitly
allocate object memory, track where it is used, and explicitly free it
for re-use. To ensure a consistent API across these platforms, the DOM
does not address memory management issues at all, but instead leaves
these for the implementation. Neither of the explicit language bindings
defined by the DOM API (for
<a href='glossary.html#dt-ECMAScript'>ECMAScript</a> and Java) require any
memory management methods, but DOM bindings for other languages
(especially C or C++) may require such support. These extensions will
be the responsibility of those adapting the DOM API to a specific
language, not the DOM Working Group.</div> <!-- div3 ID-249F15BA -->
<div class='div3'><a name='ID-45A944CB'></a>
<h3 id='ID-45A944CB-h3' class='div3'>1.1.3
Naming Conventions</h3><p>While it would be nice to have attribute and method names that are
short, informative, internally consistent, and familiar to users of
similar APIs, the names also should not clash with the names in legacy
APIs supported by DOM implementations. Furthermore, both OMG IDL [<cite><a class='noxref informative' href='references.html#OMGIDL'>OMG IDL</a></cite>] and ECMAScript [<cite><a class='noxref informative' href='references.html#ECMAScript'>ECMAScript</a></cite>] have significant limitations in their ability
to disambiguate names from different namespaces that make it difficult
to avoid naming conflicts with short, familiar names. So, DOM names
tend to be long and descriptive in order to be unique across all
environments.<p>The Working Group has also attempted to be internally consistent in
its use of various terms, even though these may not be common
distinctions in other APIs. For example, the DOM API uses the method
name "remove" when the method changes the structural model, and the
method name "delete" when the method gets rid of something inside the
structure model. The thing that is deleted is not returned. The thing
that is removed may be returned, when it makes sense to return it.</div> <!-- div3 ID-45A944CB -->
<div class='div3'><a name='ID-1CED5498'></a>
<h3 id='ID-1CED5498-h3' class='div3'>1.1.4
Inheritance vs. Flattened Views of the API</h3><p>The DOM Core <a href='glossary.html#dt-API'>APIs</a> present two somewhat
different sets of interfaces to an XML/HTML document: one presenting an
"object oriented" approach with a hierarchy of
<a href='glossary.html#dt-inheritance'>inheritance</a>, and a "simplified"
view that allows all manipulation to be done via the <a href='core.html#ID-1950641247'><code>Node</code></a>
interface without requiring casts (in Java and other C-like languages)
or query interface calls in <a href='glossary.html#dt-COM'>COM</a>
environments. These operations are fairly expensive in Java and COM,
and the DOM may be used in performance-critical environments, so we
allow significant functionality using just the <a class='noxref' href='core.html#ID-1950641247'><code>Node</code></a>
interface. Because many other users will find the
<a href='glossary.html#dt-inheritance'>inheritance</a> hierarchy easier to
understand than the "everything is a <a class='noxref' href='core.html#ID-1950641247'><code>Node</code></a>" approach to the
DOM, we also support the full higher-level interfaces for those who
prefer a more object-oriented <a href='glossary.html#dt-API'>API</a>. <p>In practice, this means that there is a certain amount of redundancy
in the <a href='glossary.html#dt-API'>API</a>. The Working Group considers
the "<a href='glossary.html#dt-inheritance'>inheritance</a>" approach the
primary view of the API, and the full set of functionality on
<a href='core.html#ID-1950641247'><code>Node</code></a> to be "extra" functionality that users may employ,
but that does not eliminate the need for methods on other interfaces
that an object-oriented analysis would dictate. (Of course, when the
O-O analysis yields an attribute or method that is identical to one on
the <a class='noxref' href='core.html#ID-1950641247'><code>Node</code></a> interface, we don't specify a completely
redundant one.) Thus, even though there is a generic
<a href='core.html#ID-F68D095'><code>Node.nodeName</code></a> attribute on the <a class='noxref' href='core.html#ID-1950641247'><code>Node</code></a> interface,
there is still a <a href='core.html#ID-104682815'><code>Element.tagName</code></a> attribute on the
<a href='core.html#ID-745549614'><code>Element</code></a> interface; these two attributes must contain the
same value, but the it is worthwhile to support both, given the
different constituencies the DOM <a href='glossary.html#dt-API'>API</a>
must satisfy.</div> <!-- div3 ID-1CED5498 --></div> <!-- div2 ID-1590626201 -->
<div class='div2'><a name='BasicTypes'></a>
<h2 id='BasicTypes-h2' class='div2'>1.2
Basic Types</h2><p>
To ensure interoperability, this specification specifies the following
basic types used in various DOM modules. Even though the DOM
uses the basic types in the interfaces, bindings may use
different types and normative bindings are only given for Java and
ECMAScript in this specification.
<div class='div3'><a name='ID-C74D1578'></a>
<h3 id='ID-C74D1578-h3' class='div3'>1.2.1
The <a href='core.html#DOMString'><code>DOMString</code></a> Type</h3><p>
The <a href='core.html#DOMString'><code>DOMString</code></a> type is used to store [<cite><a class='noxref normative' href='references.html#Unicode'>Unicode</a></cite>] characters as a sequence of <a href='glossary.html#dt-16-bit-unit'>16-bit units</a> using UTF-16 as
defined in [<cite><a class='noxref normative' href='references.html#Unicode'>Unicode</a></cite>] and Amendment 1 of [<cite><a class='noxref normative' href='references.html#ISO10646'>ISO/IEC 10646</a></cite>].
<p>
Characters are <a class='normative' href='http://www.w3.org/TR/2004/REC-xml11-20040204/#dt-fullnorm'>fully
normalized</a> as defined in appendix B of [<cite><a class='noxref normative' href='references.html#XML11'>XML 1.1</a></cite>] if:
<ul>
<li>
the parameter "<a href='core.html#parameter-normalize-characters'>normalize-characters</a>"
was set to <code>true</code> while loading the document or
the document was certified as defined in [<cite><a class='noxref normative' href='references.html#XML11'>XML 1.1</a></cite>];
</li>
<li>
the parameter "<a href='core.html#parameter-normalize-characters'>normalize-characters</a>"
was set to <code>true</code> while using the method
<a href='core.html#Document3-normalizeDocument'><code>Document.normalizeDocument()</code></a>, or while using
the method <a href='core.html#ID-normalize'><code>Node.normalize()</code></a>;
</li>
</ul>
<p>
Note that, with the exceptions of
<a href='core.html#Document3-normalizeDocument'><code>Document.normalizeDocument()</code></a> and
<a href='core.html#ID-normalize'><code>Node.normalize()</code></a>, manipulating characters using DOM
methods does not guarantee to preserve a
<i>fully-normalized</i> text.
<dl><dt><b>Type Definition <i><a name='DOMString'>DOMString</a></i></b></dt><dd>
<p>A <a href='core.html#DOMString'><code>DOMString</code></a> is a sequence of
<a href='glossary.html#dt-16-bit-unit'>16-bit units</a>.
<dl>
<dt><br><b>IDL Definition</b></dt>
<dd>
<div class='idl-code'>
<pre>
valuetype <a class='noxref' href='core.html#DOMString'>DOMString</a> sequence<unsigned short>;
</pre>
</div><br>
</dd></dl>
</dd></dl>
<p></p><p>The UTF-16 encoding was chosen because of its widespread industry
practice. Note that for both HTML and XML, the document character set
(and therefore the notation of numeric character references) is based on
UCS [<cite><a class='noxref normative' href='references.html#ISO10646'>ISO/IEC 10646</a></cite>]. A single numeric character reference in a
source document may therefore in some cases correspond to two 16-bit
units in a <a href='core.html#DOMString'><code>DOMString</code></a> (a high surrogate and a low
surrogate). For issues related to string comparisons, refer to
<a href='core.html#ID-5DFED1F0'>String Comparisons in the DOM</a>.</p><p>
For Java and ECMAScript, <a href='core.html#DOMString'><code>DOMString</code></a> is bound to the
<code>String</code> type because both languages also use UTF-16
as their encoding.
</p><p><b>Note:</b> As of August 2000, the OMG IDL specification
([<cite><a class='noxref normative' href='references.html#OMGIDL'>OMG IDL</a></cite>]) included a <code>wstring</code>
type. However, that definition did not meet the interoperability
criteria of the DOM <a href='glossary.html#dt-API'>API</a> since it
relied on negotiation to decide the width and encoding of a
character.</p>
</div> <!-- div3 ID-C74D1578 -->
<div class='div3'><a name='Core-DOMTimeStamp'></a>
<h3 id='Core-DOMTimeStamp-h3' class='div3'>1.2.2
The <a href='core.html#DOMTimeStamp'><code>DOMTimeStamp</code></a> Type</h3><p>
The <a href='core.html#DOMTimeStamp'><code>DOMTimeStamp</code></a> type is used to store an absolute
or relative time.
<dl><dt><b>Type Definition <i><a name='DOMTimeStamp'>DOMTimeStamp</a></i></b></dt><dd>
<p>A <a href='core.html#DOMTimeStamp'><code>DOMTimeStamp</code></a> represents a number of
milliseconds.
<dl>
<dt><br><b>IDL Definition</b></dt>
<dd>
<div class='idl-code'>
<pre>
typedef unsigned long long <a class='noxref' href='core.html#DOMTimeStamp'>DOMTimeStamp</a>;
</pre>
</div><br>
</dd></dl>
</dd></dl>
<p>
For Java, <a href='core.html#DOMTimeStamp'><code>DOMTimeStamp</code></a> is bound to the
<code>long</code> type. For ECMAScript, <a class='noxref' href='core.html#DOMTimeStamp'><code>DOMTimeStamp</code></a>
is bound to the <code>Date</code> type because the range of the
<code>integer</code> type is too small.
</p></div> <!-- div3 Core-DOMTimeStamp -->
<div class='div3'><a name='Core-DOMUserData'></a>
<h3 id='Core-DOMUserData-h3' class='div3'>1.2.3
The <a href='core.html#DOMUserData'><code>DOMUserData</code></a> Type</h3><p>
The <a href='core.html#DOMUserData'><code>DOMUserData</code></a> type is used to store
application data.
<dl><dt><b>Type Definition <i><a name='DOMUserData'>DOMUserData</a></i></b></dt><dd>
<p>A <a href='core.html#DOMUserData'><code>DOMUserData</code></a> represents a reference to
application data.
<dl>
<dt><br><b>IDL Definition</b></dt>
<dd>
<div class='idl-code'>
<pre>
typedef any <a class='noxref' href='core.html#DOMUserData'>DOMUserData</a>;
</pre>
</div><br>
</dd></dl>
</dd></dl>
<p>
For Java, <a href='core.html#DOMUserData'><code>DOMUserData</code></a> is bound to the
<code>Object</code> type. For ECMAScript,
<a class='noxref' href='core.html#DOMUserData'><code>DOMUserData</code></a> is bound to <code>any type</code>.
</p></div> <!-- div3 Core-DOMUserData -->
<div class='div3'><a name='Core-DOMObject'></a>
<h3 id='Core-DOMObject-h3' class='div3'>1.2.4
The <a href='core.html#DOMObject'><code>DOMObject</code></a> Type</h3><p>
The <a href='core.html#DOMObject'><code>DOMObject</code></a> type is used to represent an
object.
<dl><dt><b>Type Definition <i><a name='DOMObject'>DOMObject</a></i></b></dt><dd>
<p>A <a href='core.html#DOMObject'><code>DOMObject</code></a> represents an object reference.
<dl>
<dt><br><b>IDL Definition</b></dt>
<dd>
<div class='idl-code'>
<pre>
typedef Object <a class='noxref' href='core.html#DOMObject'>DOMObject</a>;
</pre>
</div><br>
</dd></dl>
</dd></dl>
<p>
For Java and ECMAScript, <a href='core.html#DOMObject'><code>DOMObject</code></a> is bound to the
<code>Object</code> type.
</p></div> <!-- div3 Core-DOMObject --></div> <!-- div2 BasicTypes -->
<div class='div2'><a name='Consideration'></a>
<h2 id='Consideration-h2' class='div2'>1.3
General Considerations</h2>
<div class='div3'><a name='ID-5DFED1F0'></a>
<h3 id='ID-5DFED1F0-h3' class='div3'>1.3.1
String Comparisons in the DOM</h3><p>The DOM has many interfaces that imply string matching. For
XML, string comparisons are case-sensitive and performed with a
binary <a href='glossary.html#dt-string-compare'>comparison</a> of
the <a href='glossary.html#dt-16-bit-unit'>16-bit units</a> of the
<a href='core.html#DOMString'><code>DOMStrings</code></a>. However, for case-insensitive markup
languages, such as HTML 4.01 or earlier, these comparisons are
case-insensitive where appropriate.<p>Note that HTML processors often perform specific case
normalizations (canonicalization) of the markup before the DOM
structures are built. This is typically using uppercase for
<a href='glossary.html#dt-element'>element</a> names and lowercase
for attribute names. For this reason, applications should also
compare element and attribute names returned by the DOM
implementation in a case-insensitive manner.<p>
The character normalization, i.e. transforming into their <a class='normative' href='http://www.w3.org/TR/2004/REC-xml11-20040204/#dt-fullnorm'>fully normalized</a> form as
as defined in [<cite><a class='noxref normative' href='references.html#XML11'>XML 1.1</a></cite>], is assumed to happen at
serialization time. The DOM Level 3 Load and Save module [<cite><a class='noxref informative' href='references.html#DOMLS'>DOM Level 3 Load and Save</a></cite>] provides a serialization
mechanism (see the <code>DOMSerializer</code> interface, section
2.3.1) and uses the <a href='core.html#DOMConfiguration'><code>DOMConfiguration</code></a> parameters
"<a href='core.html#parameter-normalize-characters'>normalize-characters</a>"
and "<a href='core.html#parameter-check-character-normalization'>check-character-normalization</a>"
to assure that text is <a class='normative' href='http://www.w3.org/TR/2004/REC-xml11-20040204/#dt-fullnorm'>fully normalized</a> [<cite><a class='noxref normative' href='references.html#XML11'>XML 1.1</a></cite>]. Other serialization mechanisms built on top of
the DOM Level 3 Core also have to assure that text is
<i>fully normalized</i>.
</div> <!-- div3 ID-5DFED1F0 -->
<div class='div3'><a name='domURIs'></a>
<h3 id='domURIs-h3' class='div3'>1.3.2
DOM URIs</h3><p>
The DOM specification relies on <a href='core.html#DOMString'><code>DOMString</code></a> values as
resource identifiers, such that the following conditions are
met:
<ol>
<li>
An absolute identifier absolutely identifies a resource on
the Web;
</li>
<li>
Simple string equality establishes equality of absolute
resource identifiers, and no other equivalence of resource
identifiers is considered significant to the DOM
specification;
</li>
<li>
A relative identifier is easily detected and made absolute
relative to an absolute identifier;
</li>
<li>
Retrieval of content of a resource may be accomplished where
required.
</li>
</ol>
<p>
The term "<i>absolute URI</i>" refers to a complete
resource identifier and the term "<i>relative URI</i>"
refers to an incomplete resource identifier.
<p>
Within the DOM specifications, these identifiers are called
URIs, "Uniform Resource Identifiers", but this is meant
abstractly. The DOM implementation does not necessarily process
its URIs according to the URI specification [<cite><a class='noxref informative' href='references.html#URIRef'>IETF RFC 2396</a></cite>]. Generally the particular
form of these identifiers must be ignored.
<p>
When is not possible to completely ignore the type of a DOM URI,
either because a relative identifier must be made absolute or
because content must be retrieved, the DOM implementation must
at least support identifier types appropriate to the content
being processed. [<cite><a class='noxref informative' href='references.html#HTML40'>HTML 4.01</a></cite>],
[<cite><a class='noxref informative' href='references.html#XML'>XML 1.0</a></cite>], and associated namespace
specification [<cite><a class='noxref informative' href='references.html#Namespaces'>XML Namespaces</a></cite>] rely
on [<cite><a class='noxref informative' href='references.html#URIRef'>IETF RFC 2396</a></cite>] to determine
permissible characters and resolving relative URIs. Other
specifications such as namespaces in XML 1.1 [<cite><a class='noxref informative' href='references.html#Namespaces11'>XML Namespaces 1.1</a></cite>] may rely on alternative
resource identifier types that may, for example, include
non-ASCII characters, necessitating support for alternative
resource identifier types where required by applicable
specifications.
</div> <!-- div3 domURIs -->
<div class='div3'><a name='Namespaces-Considerations'></a>
<h3 id='Namespaces-Considerations-h3' class='div3'>1.3.3
XML Namespaces</h3><p>
DOM Level 2 and 3 support XML namespaces [<cite><a class='noxref normative' href='references.html#Namespaces'>XML Namespaces</a></cite>] by augmenting several interfaces of the DOM
Level 1 Core to allow creating and manipulating <a href='glossary.html#dt-element'>elements</a> and attributes associated to
a namespace. When [<cite><a class='noxref normative' href='references.html#XML11'>XML 1.1</a></cite>] is in use (see
<a href='core.html#Document3-version'><code>Document.xmlVersion</code></a>), DOM Level 3 also supports
[<cite><a class='noxref normative' href='references.html#Namespaces11'>XML Namespaces 1.1</a></cite>].
<p>As far as the DOM is concerned, special attributes used for declaring
XML namespaces are still
exposed and can be manipulated just like any other attribute. However,
nodes are permanently bound to <a href='glossary.html#dt-namespaceURI'>namespace
URIs</a> as they get created. Consequently, moving a node
within a document, using the DOM, in no case results in a change of its
<a href='glossary.html#dt-namespaceprefix'>namespace prefix</a> or
namespace URI. Similarly, creating a node with a namespace prefix and
namespace URI, or changing the namespace prefix of a node, does not
result in any addition, removal, or modification of any special
attributes for declaring the appropriate XML namespaces. Namespace
validation is not enforced; the DOM application is responsible. In
particular, since the mapping between prefixes and namespace URIs is
not enforced, in general, the resulting document cannot be serialized
naively. For example, applications may have to declare every namespace
in use when serializing a document.<p>In general, the DOM implementation (and higher) doesn't perform any
URI normalization or canonicalization. The URIs given to the DOM are
assumed to be valid (e.g., characters such as white spaces are properly
escaped), and no lexical checking is performed. Absolute URI references
are treated as strings and <a href='glossary.html#dt-string-compare'>compared
literally</a>. How relative namespace URI references are
treated is undefined. To ensure interoperability only absolute
namespace URI references (i.e., URI references beginning with a scheme
name and a colon) should be used. Applications should use the
value <code>null</code> as the <code>namespaceURI</code>
parameter
for methods if they wish to have no namespace. In programming
languages where empty strings can be differentiated from null,
empty strings, when given as a namespace URI, are converted to
<code>null</code>.
This is
true even though the DOM does no lexical checking of URIs.<p><b>Note:</b>
<a href='core.html#ID-ElSetAttrNS'><code>Element.setAttributeNS(null, ...)</code></a> puts the attribute in
the <i>per-element-type partitions</i> as defined in
<a class='normative' href='http://www.w3.org/TR/1999/REC-xml-names-19990114'><em>XML Namespace
Partitions</em></a> in [<cite><a class='noxref normative' href='references.html#Namespaces'>XML Namespaces</a></cite>].
</p>
<p><b>Note:</b> In the DOM, all namespace declaration attributes are <em>by
definition</em> bound to the namespace URI:
"<a class='normative' href='http://www.w3.org/2000/xmlns/'>http://www.w3.org/2000/xmlns/</a>". These are the attributes
whose <a href='glossary.html#dt-namespaceprefix'>namespace prefix</a> or
<a href='glossary.html#dt-qualifiedname'>qualified name</a> is
"xmlns" as introduced in [<cite><a class='noxref normative' href='references.html#Namespaces11'>XML Namespaces 1.1</a></cite>].</p>
<p>In a document with no namespaces, the
<a href='glossary.html#dt-child'>child</a> list of an
<a href='core.html#ID-11C98490'><code>EntityReference</code></a> node is always the same as that of the
corresponding <a href='core.html#ID-527DCFF2'><code>Entity</code></a>. This is not true in a document where
an entity contains unbound <a href='glossary.html#dt-namespaceprefix'>namespace
prefixes</a>. In such a case, the
<a href='glossary.html#dt-descendant'>descendants</a> of the corresponding
<a class='noxref' href='core.html#ID-11C98490'><code>EntityReference</code></a> nodes may be bound to different
<a href='glossary.html#dt-namespaceURI'>namespace URIs</a>, depending on
where the entity references are. Also, because, in the DOM, nodes
always remain bound to the same namespace URI, moving such
<a class='noxref' href='core.html#ID-11C98490'><code>EntityReference</code></a> nodes can lead to documents that cannot be
serialized. This is also true when the DOM Level 1 method
<a href='core.html#ID-392B75AE'><code>Document.createEntityReference(name)</code></a> is used to create
entity references that correspond to such
entities, since the <a href='glossary.html#dt-descendant'>descendants</a>
of the returned <a class='noxref' href='core.html#ID-11C98490'><code>EntityReference</code></a> are unbound. While DOM Level
3 does have support for the resolution of namespace prefixes,
use of such entities and entity references should be
avoided or used with extreme care.<p>The "NS" methods, such as
<a href='core.html#ID-DocCrElNS'><code>Document.createElementNS(namespaceURI, qualifiedName)</code></a> and
<a href='core.html#ID-DocCrAttrNS'><code>Document.createAttributeNS(namespaceURI, qualifiedName)</code></a>,
are meant to be used by namespace aware applications. Simple
applications that do not use namespaces can use the DOM Level 1
methods, such as <a href='core.html#ID-2141741547'><code>Document.createElement(tagName)</code></a> and
<a href='core.html#ID-1084891198'><code>Document.createAttribute(name)</code></a>. Elements and attributes created in this
way do not have any namespace prefix, namespace URI, or local name.<p><b>Note:</b> DOM Level 1 methods are namespace ignorant. Therefore, while it is
safe to use these methods when not dealing with namespaces, using
them and the new ones at the same time should be avoided. DOM Level 1
methods solely identify attribute nodes by their
<a href='core.html#ID-F68D095'><code>Node.nodeName</code></a>. On the contrary, the DOM Level 2 methods
related to namespaces, identify attribute nodes by their
<a href='core.html#ID-NodeNSname'><code>Node.namespaceURI</code></a> and <a href='core.html#ID-NodeNSLocalN'><code>Node.localName</code></a>. Because of this
fundamental difference, mixing both sets of methods can lead to
unpredictable results. In particular, using
<a href='core.html#ID-ElSetAttrNS'><code>Element.setAttributeNS(namespaceURI, qualifiedName, value)</code></a>, an
<a href='glossary.html#dt-element'>element</a> may have two attributes
(or more) that have the same <a class='noxref' href='core.html#ID-F68D095'><code>Node.nodeName</code></a>, but different
<a class='noxref' href='core.html#ID-NodeNSname'><code>Node.namespaceURI</code></a>s. Calling <a href='core.html#ID-666EE0F9'><code>Element.getAttribute(name)</code></a> with
that <code>nodeName</code> could then return any of those
attributes. The result depends on the implementation. Similarly,
using <a href='core.html#ID-887236154'><code>Element.setAttributeNode(newAttr)</code></a>, one can set two attributes (or
more) that have different <a class='noxref' href='core.html#ID-F68D095'><code>Node.nodeName</code></a>s but the same
<a href='core.html#ID-NodeNSPrefix'><code>Node.prefix</code></a> and <a class='noxref' href='core.html#ID-NodeNSname'><code>Node.namespaceURI</code></a>. In this case
<a href='core.html#ID-ElGetAtNodeNS'><code>Element.getAttributeNodeNS(namespaceURI, localName)</code></a> will return either attribute, in an
implementation dependent manner. The only guarantee in such cases is
that all methods that access a named item by its
<code>nodeName</code> will access the same item, and all methods
which access a node by its URI and local name will access the same
node. For instance, <a href='core.html#ID-F68F082'><code>Element.setAttribute(name, value)</code></a> and
<a href='core.html#ID-ElSetAttrNS'><code>Element.setAttributeNS(namespaceURI, qualifiedName, value)</code></a> affect the node that
<a href='core.html#ID-666EE0F9'><code>Element.getAttribute(name)</code></a> and
<a href='core.html#ID-ElGetAttrNS'><code>Element.getAttributeNS(namespaceURI, localName)</code></a>,
respectively, return.</p>
</div> <!-- div3 Namespaces-Considerations -->
<div class='div3'><a name='baseURIs-Considerations'></a>
<h3 id='baseURIs-Considerations-h3' class='div3'>1.3.4
Base URIs</h3><p>The DOM Level 3 adds support for the <b>[base URI]</b> property
defined in
[<cite><a class='noxref normative' href='references.html#InfoSet'>XML Information Set</a></cite>] by providing a new attribute on the
<a href='core.html#ID-1950641247'><code>Node</code></a> interface that exposes this information. However,
unlike the <a href='core.html#ID-NodeNSname'><code>Node.namespaceURI</code></a> attribute, the
<a href='core.html#Node3-baseURI'><code>Node.baseURI</code></a> attribute is not a static piece of information
that every node carries. Instead, it is a value that is dynamically
computed according to [<cite><a class='noxref normative' href='references.html#XMLBase'>XML Base</a></cite>]. This means its value
depends on the location of the node in the tree and moving the node
from one place to another in the tree may affect its value. Other
changes, such as adding or changing an <code>xml:base</code> attribute on the node
being queried or one of its ancestors may also affect its value.
<p>One consequence of this it that when external entity references are
expanded while building a <a href='core.html#i-Document'><code>Document</code></a> one may need to add, or
change, an xml:base attribute to the
<a href='core.html#ID-745549614'><code>Element</code></a> nodes originally contained in the entity being
expanded so that the <a href='core.html#Node3-baseURI'><code>Node.baseURI</code></a> returns the correct value. In
the case of <a href='core.html#ID-1004215813'><code>ProcessingInstruction</code></a> nodes originally
contained in the entity being expanded the information is lost.
[<cite><a class='noxref informative' href='references.html#DOMLS'>DOM Level 3 Load and Save</a></cite>] handles elements as described
here and generates a warning in the latter case.
</div> <!-- div3 baseURIs-Considerations -->
<div class='div3'><a name='Embedded-DOM'></a>
<h3 id='Embedded-DOM-h3' class='div3'>1.3.5
Mixed DOM Implementations</h3><p>As new XML vocabularies are developed, those defining the vocabularies
are also beginning to define specialized APIs for manipulating XML
instances of those vocabularies. This is usually done by extending the
DOM to provide interfaces and methods that perform operations
frequently needed by their users. For example, the MathML [<cite><a class='noxref informative' href='references.html#MathML2'>MathML 2.0</a></cite>] and SVG
[<cite><a class='noxref informative' href='references.html#SVG1'>SVG 1.1</a></cite>] specifications have developed DOM extensions to allow users to
manipulate instances of these vocabularies using semantics appropriate
to images and mathematics, respectively, as well as the generic DOM XML
semantics. Instances of SVG or MathML are often embedded in XML
documents conforming to a different schema such as XHTML.
<p>
While the Namespaces in XML specification [<cite><a class='noxref normative' href='references.html#Namespaces'>XML Namespaces</a></cite>] provides a mechanism for integrating these
documents at the syntax level, it has become clear that the DOM
Level 2 Recommendation [<cite><a class='noxref informative' href='references.html#DOM2Core'>DOM Level 2 Core</a></cite>] is not rich enough to cover all the issues that
have been encountered in having these different DOM
implementations be used together in a single application. DOM
Level 3 deals with the requirements brought about by embedding
fragments written according to a specific markup language (the
embedded component) in a document where the rest of the markup
is not written according to that specific markup language (the
host document). It does not deal with fragments embedded by
reference or linking.<p>A DOM implementation supporting DOM Level 3 Core should be able to
collaborate with subcomponents implementing specific DOMs to assemble a
compound document that can be traversed and manipulated via DOM
interfaces as if it were a seamless whole.<p>The normal typecast operation on an object should support the
interfaces expected by legacy code for a given document type.
Typecasting techniques may not be adequate for selecting between
multiple DOM specializations of an object which were combined at run
time, because they may not all be part of the same object as defined by
the binding's object model. Conflicts are most obvious with the
<a href='core.html#i-Document'><code>Document</code></a> object, since it is shared as owner by the rest
of the document. In a homogeneous document, elements rely on the
Document for specialized services and construction of specialized
nodes. In a heterogeneous document, elements from different modules
expect different services and APIs from the same <a class='noxref' href='core.html#i-Document'><code>Document</code></a>
object, since there can only be one owner and root of the document
hierarchy.</div> <!-- div3 Embedded-DOM -->
<div class='div3'><a name='DOMFeatures'></a>
<h3 id='DOMFeatures-h3' class='div3'>1.3.6
DOM Features</h3><p>
Each DOM module defines one or more features, as listed in the
conformance section (<a href='introduction.html#ID-Conformance'>Conformance</a>). Features
are case-insensitive and are also defined for a specific set of
versions. For example, this specification defines the features
<code>"Core"</code> and <code>"XML"</code>, for the
version <code>"3.0"</code>. Versions <code>"1.0"</code> and
<code>"2.0"</code> can also be used for features defined in the corresponding DOM
Levels. To avoid possible conflicts, as a convention, names
referring to features defined outside the DOM specification
should be made unique. Applications could then request for
features to be supported by a DOM implementation using the
methods
<a href='core.html#ID-getDOMImpl'><code>DOMImplementationSource.getDOMImplementation(features)</code></a>
or
<a href='core.html#ID-getDOMImpls'><code>DOMImplementationSource.getDOMImplementationList(features)</code></a>,
check the features supported by a DOM implementation using the
method <a href='core.html#ID-5CED94D7'><code>DOMImplementation.hasFeature(feature, version)</code></a>, or by a specific node using
<a href='core.html#Level-2-Core-Node-supports'><code>Node.isSupported(feature, version)</code></a>. Note that when
using the methods that take a feature and a version as
parameters, applications can use <code>null</code> or empty
string for the version parameter if they don't wish to specify a
particular version for the specified feature.
<p>
Up to the DOM Level 2 modules, all interfaces, that were an
extension of existing ones, were accessible using
binding-specific casting mechanisms if the feature associated to
the extension was supported. For example, an instance of the
<code>EventTarget</code> interface could be obtained from an
instance of the <a href='core.html#ID-1950641247'><code>Node</code></a> interface if the feature
"Events" was supported by the node.
<p>
As discussed <a href='core.html#Embedded-DOM'>Mixed DOM Implementations</a>, DOM Level 3 Core
should be able to collaborate with subcomponents implementing
specific DOMs. For that effect, the methods
<a href='core.html#DOMImplementation3-getFeature'><code>DOMImplementation.getFeature(feature, version)</code></a> and
<a href='core.html#Node3-getFeature'><code>Node.getFeature(feature, version)</code></a> were
introduced. In the case of
<a href='core.html#ID-5CED94D7'><code>DOMImplementation.hasFeature(feature, version)</code></a> and
<a href='core.html#Level-2-Core-Node-supports'><code>Node.isSupported(feature, version)</code></a>, if a plus sign
"+" is prepended to any feature name, implementations are
considered in which the specified feature may not be directly
castable but would require discovery through
<a href='core.html#DOMImplementation3-getFeature'><code>DOMImplementation.getFeature(feature, version)</code></a> and
<a href='core.html#Node3-getFeature'><code>Node.getFeature(feature, version)</code></a>. Without a plus,
only features whose interfaces are directly castable are
considered.
<div class='code-block'>
<pre>// example 1, without prepending the "+"
if (myNode.isSupported("Events", "3.0")) {
EventTarget evt = (EventTarget) myNode;
// ...
}
// example 2, with the "+"
if (myNode.isSupported("+Events", "3.0")) {
// (the plus sign "+" is irrelevant for the getFeature method itself
// and is ignored by this method anyway)
EventTarget evt = (EventTarget) myNode.getFeature("Events", "3.0");
// ...
}</pre>
</div></div> <!-- div3 DOMFeatures -->
<div class='div3'><a name='Bootstrap'></a>
<h3 id='Bootstrap-h3' class='div3'>1.3.7
Bootstrapping</h3><p>Because previous versions of the DOM specification only defined a set
of interfaces, applications had to rely on some implementation
dependent code to start from. However, hard-coding the application to a
specific implementation prevents the application from running on other
implementations and from using the most-suitable implementation of the
environment. At the same time, implementations may also need to load
modules or perform other setup to efficiently adapt to different and
sometimes mutually-exclusive feature sets.<p>To solve these problems this specification introduces a
<code>DOMImplementationRegistry</code> object with a function that lets
an application find implementations, based on the specific features
it requires. How this object is found and what it exactly looks like is
not defined here, because this cannot be done in a language-independent
manner. Instead, each language binding defines its own way of doing
this. See <a href='java-binding.html#java-binding'>Java Language Binding</a> and
<a href='ecma-script-binding.html#ecma-binding'>ECMAScript Language Binding</a> for specifics.<p>In all cases, though, the <code>DOMImplementationRegistry</code>
provides a <code>getDOMImplementation</code> method accepting a
features string, which is passed to every known
<a href='core.html#DOMImplementationSource'><code>DOMImplementationSource</code></a> until a suitable
<a href='core.html#ID-102161490'><code>DOMImplementation</code></a> is found and returned.
The <code>DOMImplementationRegistry</code>
also provides a <code>getDOMImplementationList</code> method accepting a
features string, which is passed to every known
<a class='noxref' href='core.html#DOMImplementationSource'><code>DOMImplementationSource</code></a>, and returns a list of suitable
<a class='noxref' href='core.html#ID-102161490'><code>DOMImplementations</code></a>. Those two methods are
the same as the ones found on the <a class='noxref' href='core.html#DOMImplementationSource'><code>DOMImplementationSource</code></a>
interface. <p>Any number of <a href='core.html#DOMImplementationSource'><code>DOMImplementationSource</code></a> objects can be
registered. A source may return one or more
<a href='core.html#ID-102161490'><code>DOMImplementation</code></a> singletons or construct new
<a class='noxref' href='core.html#ID-102161490'><code>DOMImplementation</code></a> objects, depending upon whether the
requested features require specialized state in the
<a class='noxref' href='core.html#ID-102161490'><code>DOMImplementation</code></a> object.</div> <!-- div3 Bootstrap --></div> <!-- div2 Consideration -->
<div class='div2'><a name='ID-BBACDC08'></a>
<h2 id='ID-BBACDC08-h2' class='div2'>1.4
Fundamental Interfaces: Core Module</h2><p>The interfaces within this section are considered
<em>fundamental</em>, and must be fully implemented by all conforming
implementations of the DOM, including all HTML DOM implementations
[<cite><a class='noxref informative' href='references.html#DOM2HTML'>DOM Level 2 HTML</a></cite>], unless otherwise specified.
<p>A DOM application may use the
<a href='core.html#ID-5CED94D7'><code>DOMImplementation.hasFeature(feature, version)</code></a> method
with parameter values "Core" and "3.0" (respectively) to determine
whether or not this module is supported by the implementation. Any
implementation that conforms to DOM Level 3 or a DOM Level 3 module
must conform to the Core module. Please refer to additional
information about <a class='normative' href='http://www.w3.org/TR/DOM-Level-3-Core/introduction.html#ID-Conformance'><em>conformance</em></a> in this specification. The DOM Level 3 Core
module is backward compatible with the DOM Level 2 Core [<cite><a class='noxref informative' href='references.html#DOM2Core'>DOM Level 2 Core</a></cite>] module, i.e. a DOM Level 3 Core
implementation who returns <code>true</code> for "Core" with the
<code>version</code> number <code>"3.0"</code> must also return
<code>true</code> for this <code>feature</code> when the
<code>version</code> number is <code>"2.0"</code>, <code>""</code>
or, <code>null</code>.
<dl><dt><b>Exception <i><a name='ID-17189187'>DOMException</a></i></b></dt>
<dd>
<p>DOM operations only raise exceptions in "exceptional"
circumstances, i.e., when an operation is impossible to perform (either
for logical reasons, because data is lost, or because the implementation
has become unstable). In general, DOM methods return specific error
values in ordinary processing situations, such as out-of-bound errors
when using <a href='core.html#ID-536297177'><code>NodeList</code></a>.<p>Implementations should raise other exceptions under other circumstances.
For example, implementations should raise an implementation-dependent
exception if a <code>null</code> argument is passed when
<code>null</code> was not expected.<p>Some languages and object systems do not support the concept of
exceptions. For such systems, error conditions may be indicated using
native error reporting mechanisms. For some bindings, for example,
methods may return error codes similar to those listed in the
corresponding method descriptions.
<dl id="anuragId">
<dt><br><b class="anuragClass">IDL Definition</b></dt>
<dd>
<div class='idl-code'>
<pre>
exception <a class='noxref' href='core.html#ID-17189187'>DOMException</a> {
unsigned short code;
};
// ExceptionCode
const unsigned short <a class='noxref' href='core.html#DOMException-INDEX_SIZE_ERR'>INDEX_SIZE_ERR</a> = 1;
const unsigned short <a class='noxref' href='core.html#DOMException-DOMSTRING_SIZE_ERR'>DOMSTRING_SIZE_ERR</a> = 2;
const unsigned short <a class='noxref' href='core.html#DOMException-HIERARCHY_REQUEST_ERR'>HIERARCHY_REQUEST_ERR</a> = 3;
const unsigned short <a class='noxref' href='core.html#DOMException-WRONG_DOCUMENT_ERR'>WRONG_DOCUMENT_ERR</a> = 4;
const unsigned short <a class='noxref' href='core.html#DOMException-INVALID_CHARACTER_ERR'>INVALID_CHARACTER_ERR</a> = 5;
const unsigned short <a class='noxref' href='core.html#DOMException-NO_DATA_ALLOWED_ERR'>NO_DATA_ALLOWED_ERR</a> = 6;
const unsigned short <a class='noxref' href='core.html#DOMException-NO_MODIFICATION_ALLOWED_ERR'>NO_MODIFICATION_ALLOWED_ERR</a> = 7;
const unsigned short <a class='noxref' href='core.html#DOMException-NOT_FOUND_ERR'>NOT_FOUND_ERR</a> = 8;
const unsigned short <a class='noxref' href='core.html#DOMException-NOT_SUPPORTED_ERR'>NOT_SUPPORTED_ERR</a> = 9;
const unsigned short <a class='noxref' href='core.html#DOMException-INUSE_ATTRIBUTE_ERR'>INUSE_ATTRIBUTE_ERR</a> = 10;
// Introduced in DOM Level 2:
const unsigned short <a class='noxref' href='core.html#DOMException-INVALID_STATE_ERR'>INVALID_STATE_ERR</a> = 11;
// Introduced in DOM Level 2:
const unsigned short <a class='noxref' href='core.html#DOMException-SYNTAX_ERR'>SYNTAX_ERR</a> = 12;
// Introduced in DOM Level 2:
const unsigned short <a class='noxref' href='core.html#DOMException-INVALID_MODIFICATION_ERR'>INVALID_MODIFICATION_ERR</a> = 13;
// Introduced in DOM Level 2:
const unsigned short <a class='noxref' href='core.html#DOMException-NAMESPACE_ERR'>NAMESPACE_ERR</a> = 14;
// Introduced in DOM Level 2:
const unsigned short <a class='noxref' href='core.html#DOMException-INVALID_ACCESS_ERR'>INVALID_ACCESS_ERR</a> = 15;
// Introduced in DOM Level 3:
const unsigned short <a class='noxref' href='core.html#DOMException-VALIDATION_ERR'>VALIDATION_ERR</a> = 16;
// Introduced in DOM Level 3:
const unsigned short <a class='noxref' href='core.html#DOMException-TYPE_MISMATCH_ERR'>TYPE_MISMATCH_ERR</a> = 17;
</pre>
</div><br>
</dd>
<dt><b>Definition group <i><a name='ID-258A00AF'>ExceptionCode</a></i></b></dt>
<dd><p>An integer indicating the type of error generated.<p><b>Note:</b> Other numeric codes are reserved for W3C for possible future use.</p>
<dl>
<dt><b>Defined Constants</b></dt>
<dd><dl>
<dt><a name='DOMException-DOMSTRING_SIZE_ERR'><code class='constant-name'>DOMSTRING_SIZE_ERR</code></a></dt><dd>
If the specified range of text does not fit into a <a href='core.html#DOMString'><code>DOMString</code></a>.</dd>
<dt><a name='DOMException-HIERARCHY_REQUEST_ERR'><code class='constant-name'>HIERARCHY_REQUEST_ERR</code></a></dt><dd>
If any <a href='core.html#ID-1950641247'><code>Node</code></a> is inserted somewhere it doesn't belong.</dd>
<dt><a name='DOMException-INDEX_SIZE_ERR'><code class='constant-name'>INDEX_SIZE_ERR</code></a></dt><dd>
If index or size is negative, or greater than the allowed value.</dd>
<dt><a name='DOMException-INUSE_ATTRIBUTE_ERR'><code class='constant-name'>INUSE_ATTRIBUTE_ERR</code></a></dt><dd>
If an attempt is made to add an attribute that is already in use
elsewhere.</dd>
<dt><a name='DOMException-INVALID_ACCESS_ERR'><code class='constant-name'>INVALID_ACCESS_ERR</code></a>, introduced in <b class='version'>DOM Level 2</b>.</dt><dd>
If a parameter or an operation is not supported by the underlying
object.</dd>
<dt><a name='DOMException-INVALID_CHARACTER_ERR'><code class='constant-name'>INVALID_CHARACTER_ERR</code></a></dt><dd>
If an invalid or illegal character is specified, such as in an
XML name.</dd>
<dt><a name='DOMException-INVALID_MODIFICATION_ERR'><code class='constant-name'>INVALID_MODIFICATION_ERR</code></a>, introduced in <b class='version'>DOM Level 2</b>.</dt><dd>
If an attempt is made to modify the type of the underlying object.</dd>
<dt><a name='DOMException-INVALID_STATE_ERR'><code class='constant-name'>INVALID_STATE_ERR</code></a>, introduced in <b class='version'>DOM Level 2</b>.</dt><dd>
If an attempt is made to use an object that is not, or is no longer,
usable.</dd>
<dt><a name='DOMException-NAMESPACE_ERR'><code class='constant-name'>NAMESPACE_ERR</code></a>, introduced in <b class='version'>DOM Level 2</b>.</dt><dd>
If an attempt is made to create or change an object in a way which is
incorrect with regard to namespaces.</dd>
<dt><a name='DOMException-NOT_FOUND_ERR'><code class='constant-name'>NOT_FOUND_ERR</code></a></dt><dd>
If an attempt is made to reference a <a href='core.html#ID-1950641247'><code>Node</code></a> in a context where it does
not exist.</dd>
<dt><a name='DOMException-NOT_SUPPORTED_ERR'><code class='constant-name'>NOT_SUPPORTED_ERR</code></a></dt><dd>
If the implementation does not support the requested type of object or
operation.</dd>
<dt><a name='DOMException-NO_DATA_ALLOWED_ERR'><code class='constant-name'>NO_DATA_ALLOWED_ERR</code></a></dt><dd>
If data is specified for a <a href='core.html#ID-1950641247'><code>Node</code></a> which does not support data.</dd>
<dt><a name='DOMException-NO_MODIFICATION_ALLOWED_ERR'><code class='constant-name'>NO_MODIFICATION_ALLOWED_ERR</code></a></dt><dd>
If an attempt is made to modify an object where modifications are not
allowed.</dd>
<dt><a name='DOMException-SYNTAX_ERR'><code class='constant-name'>SYNTAX_ERR</code></a>, introduced in <b class='version'>DOM Level 2</b>.</dt><dd>
If an invalid or illegal string is specified.</dd>
<dt><a name='DOMException-TYPE_MISMATCH_ERR'><code class='constant-name'>TYPE_MISMATCH_ERR</code></a>, introduced in <b class='version'>DOM Level 3</b>.</dt><dd>
If the type of an object is incompatible with the expected type
of the parameter associated to the object.
</dd>
<dt><a name='DOMException-VALIDATION_ERR'><code class='constant-name'>VALIDATION_ERR</code></a>, introduced in <b class='version'>DOM Level 3</b>.</dt><dd>
If a call to a method such as <code>insertBefore</code> or
<code>removeChild</code> would make the <a href='core.html#ID-1950641247'><code>Node</code></a> invalid with
respect to <a href='glossary.html#dt-partially-valid'>"partial
validity"</a>, this exception would be raised and the operation
would not be done. This code is used in [<cite><a class='noxref informative' href='references.html#DOMVal'>DOM Level 3 Validation</a></cite>]. Refer to this specification for further information.</dd>
<dt><a name='DOMException-WRONG_DOCUMENT_ERR'><code class='constant-name'>WRONG_DOCUMENT_ERR</code></a></dt><dd>
If a <a href='core.html#ID-1950641247'><code>Node</code></a> is used in a different document than the one that created it
(that doesn't support it).</dd>
</dl>
</dd></dl>
</dd>
</dl></dd>
</div>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>Ready to run.
| Test | Ops/sec | |
|---|---|---|
| #someId > .someClass | | ready |
| $('#someId').find('.someClass') | | ready |
| $('.someClass') | | ready |
| $('#someId') | | ready |
You can edit these tests or add more tests to this page by appending /edit to the URL.