I use serverside code as a graceful-failure option using the same XSLT as the Javascript uses. The most convenient DOM method for me is XSLTProcessor.transformToFragment(xml, targetDocument); however, I’ve had to enhance Anthony’s importNode() to import the transformed XHTML as a DocumentFragment. Here’s the additional case (looks familiar, doesn’t it?):
case document.DOCUMENT_NODE:
var newNode = document.createDocumentFragment();
if (allChildren && node.childNodes && node.childNodes.length > 0)
for (var i = 0, il = node.childNodes.length; i < il;)
newNode.appendChild(document._importNode(node.childNodes[i++], »
allChildren));
return newNode;
break;
The method uses a similar implementation of the adoptNode() function that includes tweaks for the Missing TBody Problem, the Special IE Attribute Names (className, CSSText, HTMLFor) and the Attribute Case Sensitiveness Problem.
Copy & paste the code below to embed this comment.
richardh
Firstly I buy 100% into your requirement and philosophy Anthony and I would like to thank you for taking the time to write such an amazing article.
Secondly, I would like to point the following out to the narrow minded JSON zealots in your post and also hopefully assist those who as a result are being exposed to their comments:- While JSON absolutely has it’s place, you and your programming will always benefit by broadening your outlook. Don’t assume that any one solution is best all the time every time.
There are many reasons why XHTML has a place. One reason for example is that XML is adopted right into the core of many databases and at a simplistic level this means that using XHTML internally (or a stripped down version) allows one to pass data from the core to the user with minimal/ even no transformation (and please can I ask any commenters not to labour the “gee, but that is inefficient in a database” point as the details of this aspect are well known to me) . Another is the massive supporting framework that exists for XML, a quick example being XSLT; which allows simple, elegant data transformations to XML data. Combining simplicity and elegance in my book makes for great programmatic results.
So whether you choose JSON or XHTML for your particular purpose, no matter. In my case I will for sure be taking advantage of this wonderful post.
Copy & paste the code below to embed this comment.
richardh
Just a quick update that thanks to your article, from now on it will take just 2 lines of code for me to take any subtree of a response XHTML document and append the entire subtree to any branch of the current document – and that I have tested this successfully on IE 6,7,8, FF3, current Opera, current Chrome and current Safari
Of particular benefit was
if (!document.importNode) {
parentNode[removed] = parentNode[removed];
}
for IE 6 and 7, which would have taken me an unknown amount of time to identify – as IE6 and IE7 throw no errors if this is omitted and simply displays “nothing”
And one last note is that I highly recommend that people stay away from innerHTML as quirks that I saw with it, even in the latest firefox were what started me on the dom investigation in the first place – you simply cannot be sure when innerHTML will not work…
Thanks again and good luck to all others out there grappling with cross browser compatibility – I highly recommend taking advantage of this fantastic article.
34 Reader Comments
Back to the ArticleMichael Smith
I use serverside code as a graceful-failure option using the same XSLT as the Javascript uses. The most convenient DOM method for me is XSLTProcessor.transformToFragment(xml, targetDocument); however, I’ve had to enhance Anthony’s importNode() to import the transformed XHTML as a DocumentFragment. Here’s the additional case (looks familiar, doesn’t it?):
case document.DOCUMENT_NODE:
var newNode = document.createDocumentFragment();
if (allChildren && node.childNodes && node.childNodes.length > 0)
for (var i = 0, il = node.childNodes.length; i < il;)
newNode.appendChild(document._importNode(node.childNodes[i++], »
allChildren));
return newNode;
break;
ccblogger
Thanks for the article and comments, I found it very useful.
Check out the following post to see how to create pure HTML templates that are compatible with IE:
http://ccsoftwarefactory.com/blog/index.php/2009/10/26/html-templates-with-javascript-and-external-xml
The method uses a similar implementation of the adoptNode() function that includes tweaks for the Missing TBody Problem, the Special IE Attribute Names (className, CSSText, HTMLFor) and the Attribute Case Sensitiveness Problem.
Comments welcome.
Cheers!
richardh
Firstly I buy 100% into your requirement and philosophy Anthony and I would like to thank you for taking the time to write such an amazing article.
Secondly, I would like to point the following out to the narrow minded JSON zealots in your post and also hopefully assist those who as a result are being exposed to their comments:- While JSON absolutely has it’s place, you and your programming will always benefit by broadening your outlook. Don’t assume that any one solution is best all the time every time.
There are many reasons why XHTML has a place. One reason for example is that XML is adopted right into the core of many databases and at a simplistic level this means that using XHTML internally (or a stripped down version) allows one to pass data from the core to the user with minimal/ even no transformation (and please can I ask any commenters not to labour the “gee, but that is inefficient in a database” point as the details of this aspect are well known to me) . Another is the massive supporting framework that exists for XML, a quick example being XSLT; which allows simple, elegant data transformations to XML data. Combining simplicity and elegance in my book makes for great programmatic results.
So whether you choose JSON or XHTML for your particular purpose, no matter. In my case I will for sure be taking advantage of this wonderful post.
Thank you again
richardh
Just a quick update that thanks to your article, from now on it will take just 2 lines of code for me to take any subtree of a response XHTML document and append the entire subtree to any branch of the current document – and that I have tested this successfully on IE 6,7,8, FF3, current Opera, current Chrome and current Safari
Of particular benefit was
if (!document.importNode) {
parentNode[removed] = parentNode[removed];
}
for IE 6 and 7, which would have taken me an unknown amount of time to identify – as IE6 and IE7 throw no errors if this is omitted and simply displays “nothing”
And one last note is that I highly recommend that people stay away from innerHTML as quirks that I saw with it, even in the latest firefox were what started me on the dom investigation in the first place – you simply cannot be sure when innerHTML will not work…
Thanks again and good luck to all others out there grappling with cross browser compatibility – I highly recommend taking advantage of this fantastic article.