W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] DOMParser / XMLSerializer

From: Brett Zamir <brettz9@yahoo.com>
Date: Thu, 21 May 2009 07:48:59 +0800
Message-ID: <4A1496EB.9010309@yahoo.com>
Anne van Kesteren 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?
>
>
>    


1) As far as non-privileges uses, DOMParser().parseFromString() has a 
second argument, for application type (e.g., "text/xml"). Trying 
"application/xhtml" with a code snippet using an HTML entity did not 
avoid an entity parsing error in Firefox, so I'm not aware how this 
argument is fully used, except that in extension code it does set 
Mozilla's custom "document.contentType" property. (Speaking of which, 
while the HTML5 spec states, "A Document object created by the 
createDocument() API on the DOMImplementation object is initially an XML 
document, but can be made into an HTML document by calling 
document.open() on it.",  how about adopting the Mozilla 
"document.contentType" so it can be set to "text/html" or 
"application/xhtml+xml"? This seems easier and more intuitive than 
calling something which sounds like it will open a new window, even 
though I know it does not in this case.)
2) It seems to me a bit hackish if one is forced to set up or create 
hidden nodes to get parsed or serialized content in an existing document 
(unless the node is supposed to be placed there), while using 
document.implementation.createDocument() for this seems almost to have 
the same syntactical overhead as using the DOM3L&S API.
3) Will it work with non-XHTML XML? (If not, that's disadvantageous, and 
if it does (as seems to be the case from the docs), "innerHTML" becomes 
a bit of a misnomer here.)

Brett
Received on Wednesday, 20 May 2009 16:48:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:49 UTC