If I understand Talin correctly the issue is with subtle selector (or other DOM query/manipulation) bugs caused by the fact that the original page template has a mismatched tag or something else that ends up creating a radicaly different DOM structure in the browser than you would expect by looking at the template.

As far as Dreamweaver goes, I think the rise of CSS an making your html more structural than layout-oreinted has pushed many (perhaps most) of the good web designers I know to either switch to the Code View as their primary Dreamweaver interface, or move on to other tools.

It’s interesting to hear that you went with a non-xml tag based approach to make the logic visible in the WSYWIG tool. The problem I see with that is that WSYWIG tools sometimes mess with that kind of structure, and end up breaking things. But, I think this is less and less of an issue as the tools have gotten better.

Not that this has anything to do with Templating, but I’m interested to hear you’re using almost all JSON, since I’ve done the same. But I still find that about 10-20% of the time I return HTML snippits to be inserted into the current page. I don’t ever return XML, but returning HTML still seems perfectly sensible to me. Is there any reason you’ve stopped doing that?.

That said, I can’t remember the last time I worked with someone who used a WYSIWYG tool for editing HTML (other than for previewing).

@Talin: I’ve switched to using JSON for pretty much all of my Ajax work, which makes template languages for Ajax work irrelevant (I just dump the output of simplejson straight in to a Django HttpRequest object).

You do have to limit yourself if you’re going to make Genshi work with Dreamweaver, and you’ll have to clean up after dreamweaver more often than you’d like. But if you *are* working with people who use dreamweaver, a tag based markup language is way better than a string-based markup system.

And designers can (and in my experience the good ones do) learn how to work with the underlying structure in dreamweaver too, so it’s not quite as bad as you suggest.

Having had similar experiences to yours w/r/t Dreamweaver, I now consider the whole concept of WYSIWYG HTML editing to be dubious for anything other than mostly-static web pages.

This isn’t just a problem with HTML, its really a problem with WYSIWYG as a general concept, which is that WYSIWYG editors are designed to edit the surface presentation of a document, and not the deep generative structure. That’s fine if your presentation is static and non-adaptive, but once you get into the realm of procedurally-generated layout and content you have to start thinking at the level of algorithms and behavior. Simply editing the final output product of the algorithm doesn’t buy you much.

But in Zope even though TAL didn’t really deliver on it’s Dreamweaver integration marketing promises, TAL stood the test of time and many people using TAL clutch onto it’s syntax or bring it with them when they work in non-Zope frameworks. e.g. using SimpleTAL in Django:

http://www.agmweb.ca/blog/andy/2029/

Aside from the motiviation of avoiding having to learn a new syntax,
the reason for this affinity for attribute based templates is that the
resulting template *looks* as close as possible to the final output. When
developing a web app, we often inspect the result of a templated view
using Firebug or other tools let us view the HTML source. Then when
switching back to the corresponding template, it’s nice to have something
that looks as close as possible to the resulting HTML output.

Here’s a screenshot comparing an admittedly simple example of
Django templates w/ SimpleTAL with a possible HTML result produced from of either of these templates:

http://www.bud.ca/resources/django-templates-simpletal.png

Good point, and one which I hope to address in another blog post soon. I think this is a form of “programmer friendliness” and I think that is the often under appreciated other side of this issue. PHP and classic ASP have produced so much spaghetti code that it’s hard for people to see that more power in a template language can actually lead to more maintainable code.

Talin:

A promise of correct output is a very important thing, particularly in modern web applications which as often as not return “something other” than flat HTML pages. That something other could be RSS feeds, or heavily DOM dependent Ajax, or Atom, or any of a wide varity of data-types where getting the XML (or XHTML) right is *critical.*

That too is another blog post for another day ;)

I think of Genshi as the perfect way of letting me write markup that makes sense to me that gets processed by match templates etc. in order to generate markup that makes sense to the browser.

That is to say, when I use Genshi, it’s at a very high level, whereas when I use Django templates, it’s at a much lower level. It’s hard to fully convey this point until you’ve had a bunch of experience with both.

Designing an AJAX app requires designing at the level of the DOM – you’re not just creating HTML, you are creating a tree structure that is meant to be manipulated by your JavaScript code. Minor syntactical errors which impact the parent/child relationships of the page elements can take a long time to debug, especially given the relatively poor debugging facilities of many browsers. (Although the existence of FireBug somewhat mitigates this argument.)

So in my view, the primary advantage of Genshi is not its compatibility with WYSIWYG tools, but the fact that it operates at the node level rather than on a stream of text. This makes the template structure conceptually closer to what is eventually going to end up in the browser.

On the other hand, if you really are generating content that is mostly server-generated text with a fixed layout, then a text-based templating system may be the way to go.