However, I wasn’t satisfied what caused the newline to be parsed wrongly, and why IE only. The good thing with Open Source is we get to dig in ourselves to troubleshoot issues.
After stepping through the cause is identified: multiple continuous \n not parsed correctly. Apparently someone hit this at least 5 years ago and there was a fix for it, by detecting the additional \n and eating it up. But it still fails if there are more \n.
Why IE only? We were using script tags as the template, and in IE script.innerHTML is prefixed with an additional \n.
The following snippet will fail in IE, but pass in FF.
<html> <head> <script src="trimpath-template-1.1.2.js"></script> </head> <body> <script id="src" type="text/html"> Test </script> <div id="out"></div> <script> document.getElementById("out").innerHTML = TrimPath.processDOMTemplate("src", null); </script> </body> </html>
If another newline is added (with no additional whitepsace), FF will fail with the same error.
If <textarea> instead of <script> is used, it will pass, but adding more newlines will also cause it to fail.