Layouts

The traditional way of using templates is: First, you jump into your code, initialize vars, and then, execute a template that includes some sort of pseudo-language to insert those vars inside markup.
Let's start with HTML.HTML is a language that, by reading its own and related (css,etc) specs, it's composed by tags that are meant to stylize what's inside them.Only a bunch of those tags have some sort of notion of what it's outside them, so they are part of a bigger structure: &lt:td>, inputs in a <form> , <li> etc.
But websites are not made of a bunch of independents, stacked <div>'s .
There are menus, sidebars, headers, footers, and quite a few different ui elements, each one of those composed by a few divs, and each one of those divs has a semantic role , in terms of that ui element.
Divs are to UI elements what assembler is to C.We're creating user interfaces using the most simple elements possible.There are no intermediate abstractions.We (struggle to) create a menu for our website, by combining divs and css.But that menu has only existence once it's rendered, and the user interprets those coloured divs or uls, as a "menu".
Nowhere in our code (except comments), has assigned that role to that bunch of markup.Once you start creating the user interface, you directly jump in the HTML and CSS madness.

So, it's not strange that Javascript has taken the role of creating the user interface.Libraries / frameworks like The Dojo Toolkit do a great work leveraging the concepts a programmer has to use to create user interfaces.
I think that's a big slap in the face to HTML.Sorry, HTML5, you're so great at doing things Flash was doing a decade ago, and still, fail miserably at giving any better support for creating serious UIs.

So, HTML has basically been reduced to the <div> tag, that you can convert to anything, using CSS (then, some folks still try to give "semantic" meaning to HTML).And, on top of that, use javascript to do the real rendering.
To see things in perspective: it's like we were writing components in the old Visual Studio 4, instantiating objects, but also, editing the .res files by hand.We're creating user intefaces programatically (javascript), and fighting with divs, css and browser incompatibilities.

So, after all that, is there a way to describe an user interface, in a more abstract way, and without resorting to javascript-based UI construction (so we keep javascript's small resources for our own purposes instead sustituying the browser rendering engine?)

What about this:

   [_MENU]
        [_MENUGROUP]
                [_TITLE]Main Navigation[/TITLE]
                [_OPTIONS]
                          [_OPTION][_LABEL]Home[/LABEL][_URL]http://...[/URL][/OPTION]
                          [_OPTION][_LABEL]...[/LABEL][_URL]http://...[/URL][/OPTION]
                          ...
                 [/OPTIONS]
        [/MENUGROUP]
        [_MENUGROUP]
                 [_TITLE]Support[/TITLE]
                 ....
   [/MENU]                                                  

Again, just by reading the above code, you'd know what's supposed to do.If i had written all that in its <div>, <ul>, <a>, etc equivalents, with all their css classes, attributes and so, you'd still be looking at the code trying to figure out what's its purpose. And, again, i've said nothing about how this code should be rendered.Is it a navigation bar?Is it some sort of tabbed widget? That doesnt matter; again, we're using abstractions we all know, like "Menu", and leaving out implementation details.That will be solved at a lower level. I've attempted to write template engines (like this one) to support this kind of structures, and, although they're not perfect, they did the job.But now, i think i've found the right way to do it...And hope to post some code soon! Stay connected!