Test case details

Preparation Code

<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>]  &nbsp; [<a title='Changes' accesskey='n' href='changes.html'><strong><u>n</u></strong>ext</a>] &nbsp; [<a title='Table of Contents' accesskey='c' href='Overview.html#contents'><strong><u>c</u></strong>ontents</a>] &nbsp; [<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&#xe9;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&lt;unsigned short&gt;; </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>

Test cases

Test #1

$('.anuragClass')

Test #2

$('#anuragId')

Test #3

$('b.anuragClass')

Test #4

$('dl#anuragId')