<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 16, 2011, at 12:28 PM, Mike Samuel wrote:</div><br><blockquote type="cite"><div><br>DOMString is defined at<br><a href="http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-C74D1578">http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-C74D1578</a> thus<br><br>    Type Definition DOMString<br>    A DOMString is a sequence of 16-bit units.<br><br>so how would round tripping a JS string through a DOM string work?<br></div></blockquote><div><br></div><div>Because, the DOM spec. says: "Applications must encode <a href="http://www.w3.org/TR/DOM-Level-2-Core/core.html#DOMString"><code>DOMString</code></a> using UTF-16
(defined in [<a class="noxref" href="http://www.w3.org/TR/DOM-Level-2-Core/references.html#Unicode">Unicode</a>] and Amendment 1 of [<a class="noxref" href="http://www.w3.org/TR/DOM-Level-2-Core/references.html#ISO10646">ISO/IEC
10646</a>])." it must continue to do this.</div><div><br></div><div>Values return as DOM strings would (21-bit char enhanced) ES strings where each string character contained a 16-bit UTF-16 code unit.  Just like they do now. Processing of such strings would have to do explicit surrogate pair processing just like they do now.  However, such a string could be converted to a non-UTF-16 ecoded string by explicitly user code or via a new built-in function such as:</div><div>   String.UTF16Decode(aDOMStringValue)</div><div><br></div><div>For passing strings from ES to a DOMString we have to do the inverse conversions. If explicit decoding was done as suggested above then explicit UTF-16 encoding probably should be done. But note that the internal representation of the string is likely to know if the an actual string contains any characters with codepoints > \uffff.  It may be reasonable to assume that strings without such characters are already DOMString encoded but that stings with such characters should be automatically UTF-16 encoded when they are passed as DOMString values.</div><br><blockquote type="cite"><div><br>How would<br><br>    var oneSupplemental = "\U00010000";<br></div></blockquote>I don't think I understand you literal notation. \U is a 32-bit character value?  I whose implementation?<br><blockquote type="cite"><div>    alert(oneSupplemental.length);  //  alerts 1<br></div></blockquote>I'll take your word for this<br><blockquote type="cite"><div>    var utf16Encoded = encodeUTF16(oneSupplemental);<br>    alert(utf16Encoded.length);  //  alerts 2<br></div></blockquote>yes<br><blockquote type="cite"><div>    var textNode = document.createTextNode(utf16Encoded);<br>    alert(textNode.nodeValue.length);   // alerts ?<br></div></blockquote>2<br><blockquote type="cite"><div>Does the DOM need to represent utf16Encoded internally so that it can<br>report 2 as the length on fetch of nodeValue?</div></blockquote>However the DOM representations DOMString values internally, to conform to the DOM spec. it must act as if it is representing them using UTF-16.<br><blockquote type="cite"><div>If so, how can it<br>represent that for systems that use a UTF-16 internal representation<br>for DOMString?<br></div></blockquote>Let me know if I haven't already answered this.<br><blockquote type="cite"><div><br><font class="Apple-style-span" color="#006312"><br></font></div></blockquote>Allen</div><br></body></html>