The following subsections detail the normative variations from MUST requirements in [DOM Level 3 - Core].
NODE_DOCUMENTBut what is subnodes and what is text ?
Returns a string representing the value of the node.
This is the concatenated text of
all subnodes with entities expanded.
<?xml version="1.0" encoding="utf-8" ?>
<!-- Document level comment -->
<!-- TODO: NOTATION -->
<!DOCTYPE root [
<!ENTITY ent1 "expanded ent1">
]>
<?pi1 ?>
<root attribute="attribute.value">
element.text.1
<e1><![CDATA[cdata.content]]></e1>
<e2><!--comment.content--></e2>
<e3>&ent1;</e3>
element.text.2
</root>
Remarks section clarifies something:When concatenated, the text represents the contents of text or CDATA nodes. All concatenated text nodes are normalized according to xml:space attributes and the value of the preserveWhiteSpace switch. Concatenated CDATA text is not normalized. (Child nodes that contain NODE_COMMENT and NODE_PROCESSING_INSTRUCTION nodes are not concatenated.) .text trims the whitespace on the edges of the result, and "normalizes" \r\n => \n, but otherwise just concatenates text.For this sample it returns:
Retrieves and sets the string representing the text contents of this node or the concatenated text representing this node and its descendants.
For more precise control over text manipulation in an XML document, use the lower-level nodeValue property, which returns the raw text associated with a NODE_TEXT node.
element.text.1 cdata.content expanded ent1 element.text.2Both comments skipped, OK, but I still, miss the text of my NODE_ENTITY.
expanded ent1So I would expect:
expanded ent1 element.text.1 cdata.content expanded ent1 element.text.2Why is NODE_ENTITY.text missing from NODE_DOCUMENT.text ? Maybe because it is inside NODE_DOCUMENT_TYPE which claims to return .text as "" ? Or because :text", does not mean text but nodeValue which is defined as null for both NODE_DOCUMENT_TYPE and NODE_ENTITY.
A string defining the namespace URI. If specified, the node is created in the context of
the namespaceURI parameter with the prefix specified on the node name.
If the name parameter does not have a prefix, this is treated as the default namespace.
var root = d.createNode(1, "root", "nsRoot"),
ch1 = d.createNode(1, "p:child", "nsChild"),
ch2 = d.createNode(1, "child", "nsChild"),
a1 = d.createNode(2, "p2:a1", "nsAttr"),
a2 = d.createNode(2, "a2", "nsAttr");
root.appendChild(ch1);
root.appendChild(ch2);
ch2.setAttributeNode(a1);
ch2.setAttributeNode(a2);
The last line will fail, with "bit problematic to interpret" error,There was a Namespace conflict for the '' Namespace.
<root xmlns="nsRoot">
<p:child xmlns:p="nsChild"/>
<child xmlns="nsChild" xmlns:p2="nsAttr" p2:a1=""/>
</root>
set("ns1","a:a","1")
old=getAttributeWithXPath
set("ns1","b:a","2")
new=getAttributeWithXPath
print compare pointers
print new.nodeName
print new.value
print serialized xml
Note: 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 nodeName. On the contrary, the DOM Level 2 methods related to namespaces, identify attribute nodes by their namespaceURI and localName. Because of this fundamental difference, mixing both sets of methods can lead to unpredictable results. In particular, using setAttributeNS, an element may have two attributes (or more) that have the same nodeName, but different namespaceURIs. Calling getAttribute with that nodeName could then return any of those attributes. The result depends on the implementation. Similarly, using setAttributeNode, one can set two attributes (or more) that have different nodeNames but the same prefix and namespaceURI. In this case getAttributeNodeNS 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 nodeName 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, setAttribute and setAttributeNS affect the node that getAttribute and getAttributeNS, respectively, return.
Generally it is not good idea to throw exception in event handler.
However people are lazy and bugs happen, so let's see out chances in this situation.
xhr.onreadystatechange=function(){throw new Error();}
MSIE and FF supports window.onerror event, so uncought exceptions can end up in
this global handler.
All browsers support some sort of "display JavaScript errors" but usually well hidden
as small icon on status bar (MSIE) or deeply in menus (other browsers).
Uniform handling is almost impossible. The very first idea was to rely on
window.error in MSIE an FF and call window.onerror explicitly in
other browsers (even if the browser does not support this error you can define
window.onerror=function...
and call it using window.onerror(msg,..,...) syntax.
However situation is even worse.
Msxml3.XMLHTTPShame, the sample comes from PPKs highly credited web site http://www.quirksmode.org/js/xmlhttp.html
<!DOCTYPE page [
<!ENTITY ent1 "internal">
<!ENTITY ent2 SYSTEM "test2.xml">
]>
<root>
<e1>&ent1;</e1>
<e2>&ent2;</e2>
</root>
