Re: [whatwg] DOMParser / XMLSerializer
Anne van Kesteren wrote: 2) DOMParser can parse from a byte array instead of a string; this makes it a little easier to work with XML in encodings other than UTF-8 or UTF-16. ECMASCript doesn't have byte arrays though. (Though it would be nice if it did.) Sure, but it has arrays that you can put integers in the 0-255 range into. 2) XMLSerializer can serialize a subtree rooted at a given node without removing the node from its current location in the DOM. Isn't this true for innerHTML too? No, you'd need outerHTML for that. At least if you want to get the same behavior as XMLSerializer has. -Boris
[whatwg] DOMParser / XMLSerializer
Although it seems most browsers have adopted these APIs, HTML5 offers basically identical APIs in the form of document.innerHTML or is there something that DOMParser / XMLSerializer can do that document.innerHTML cannot? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] DOMParser / XMLSerializer
On Wed, 20 May 2009 23:20:34 +0200, Anne van Kesteren ann...@opera.com wrote: Although it seems most browsers have adopted these APIs, HTML5 offers basically identical APIs in the form of document.innerHTML or is there something that DOMParser / XMLSerializer can do that document.innerHTML cannot? XMLSerializer must generate well formed xml (all tags closed, no attributes without values, case preserved, etc) and it accepts a full document, so you get a serialized output with doctype, processing instructions, comments which are not descendants of the root, and the root itself. DOMParser parses xml into a full document so if I have a doctype subset, those will be recognized and replaced on the document. That does not happen with innerHTML. If the input source has processing instructions, these will be preserved also in the result document. These are duplicates of the functionality provided on DOM 3 LS, and developer prefer these because their APIs are simpler and more convenient.
Re: [whatwg] DOMParser / XMLSerializer
On Wed, May 20, 2009 at 2:20 PM, Anne van Kesteren ann...@opera.com wrote: Although it seems most browsers have adopted these APIs, HTML5 offers basically identical APIs in the form of document.innerHTML or is there something that DOMParser / XMLSerializer can do that document.innerHTML cannot? Mostly I think these APIs came about before innerHTML was supported in XML content. DOMParser is also somewhat more convenient if you want a full document back. And XMLSerializer is more convenient if you want an XML serialization of text/html content. / Jonas
Re: [whatwg] DOMParser / XMLSerializer
Anne van Kesteren wrote: or is there something that DOMParser / XMLSerializer can do that document.innerHTML cannot? Ignoring the non-web-facing functionality (like parsing from and serializing to streams), and speaking only of Gecko's implementations, basically the following: 1) DOMParser can parse as a given content type (in theory XML vs HTML; I assume that if document.innerHTML doesn't do that yet it could be changed to do so). 2) DOMParser can parse from a byte array instead of a string; this makes it a little easier to work with XML in encodings other than UTF-8 or UTF-16. 2) XMLSerializer can serialize a subtree rooted at a given node without removing the node from its current location in the DOM. -Boris
