I think there is some value here but I also think its too heavy handed - the bads I see are...<p>- Performance - complex DOM structures will inevitably lead to many function calls. Some might argue that it is probably minor but there are going to be many many instances where a dom element is being reconstructed on every render where it could simply have been just a plain string.<p>- Readability - perhaps its personal but I find the readability of what is essentially going to be an extremely long statement in JS to be inferior to well formatted XML/CSS<p>- Error recovery / exception handling - seemingly if one of your elements/function calls goes bad your whole template is likely dead. Perhaps this could be seen as a feature.<p>- Namespacing - to cover all of the features of HTML you'll likely have to have quite a few functions declared and there is potential for an inadvertent overwrite. ex. var VIDEO = function() { return "Ooops, I just killed my video elements"; } On top of it there is risk of not being backwards compatible with older created templates as the HTML spec progresses and new functions need to be added. The simple solution is to namespace all your HTML functions but this is another layer of stuff and detracts from the simplicity.
I like it. Saw a similar approach in Firebug's domplate. dom-o looks cleaner.<p>I really like the pitch to "Reduce the number of moving parts" at the cost of small learning curve.
That's really interesting for HTML, as DOM manipulation in JS became essential. But I'm less convinced about putting CSS here (just as I won't do with any other templating system).
What about media queries, browser or device specific stylesheets ? And readability, after all<p>Also, I suggest namespacing all of your functions and using with(YOUR_DOM-O_NAMESPACE) { your dom construction here }