@Jeff Pants, I must admit that's a very elegant way to split hairs. I approve this method when it comes to produce data-oriented documents, like RSS feeds, data exports in XML, and the like. When you need real-world HTML you'll be needing to add conditional attributes, javascript events, and when it comes to tweak that HTML code to please all browsers, that level of abstraction is just going to be plain nightmare.

I agree with Bloodboiler, in the real world you want to be picky about you HTML output. Like @hombre said, HTML is the problem. And you can try as hard as you want, that problem isn't going to vanish because you hide it below your carpet. A designer absolutely needs to see what the HTML output will look like and anything trying to hide that HTML is going to fail once you need to refactor the HTML to change the layout or please all the browsers. You don't want to dig around generator functions to see where is that tag id you use in your ajax processing.

Atwood sees 20 lines of code he can't read and immediately concludes everything must be thrown in the wastebasket, without even wondering if it can be refactored, only a few guys mention we can use helper functions to tidy up that code, while about everyone else suggest square wheels so they can climb up stairs. Amazing.

Okay, I must be over-reacting and mixing OP with the soup of over-agreeing comments \o/.

That good spaghetti code metaphor is clever, like Jeff's mention to Operation was quite entertaining. But that's way beside the point.

Okay, so Jeff is just asking what we think, wondering if there is good tag soup, and I completely forgot that when I read following comments.

I got quite angry when I read that post about the subject :
http://paraesthesia.com/archive/2008/07/21/tag-soup.aspx

Some folks argue they want that tighter control over the HTML that the tag soup provides. I, personally, am much less interested in hacking HTML. Let the framework do it for me. I'm more concerned with the business logic anyway.

1) promoting just-hide-it-under-the-carpet techniques
2) let the framework do it for me - doesn't work. a) either your pages are trivial and you don't need such a framework in the first place b) when you try fancy stuff the framework gets in the way so you miss the whole point having such a framework.
3) That classic I, personally, am much less interested in hacking HTML making the whole article absolutely pointless, basically saying : your bike sucks, I don't like you pedals, the saddle is uncomfortable, I don't want to use gears ... Oh, and by the way, I don't even like biking.

For the record, I liked RoR, using helper functions and partials. I'm now on turbogears ( python + cherrypy + genshi), not my choice, but not so bad. Toscawidgets is quite elegant to isolate html components, grouping the html template, required css, javascript and validating code in one place, and still having solid control of what the ouput looks like. With some tweaking, one can easily provide form validation after a submission or through ajax ( allowing real-time checks like username availability, etc. ) with the same validation code. genshi is more a template system than a tag soup, and I guess we have the best of two worlds since it's XML ( so it can be validated ) with python inside special attributes. With cherrypy's append_variables you can easily provide helper function from outside the template.

But really, if you want so much custom stuff your framework has to give you A LOT of control over the produced HTML, and that doesn't prevent you from keeping things tidy. I guess I'd like django if I had a chance to try someday.

Correct me if I'm wrong but the few examples I've seen of asp.net's MVC look pretty much like a ruby on rails ripoff : the controller, view and routing syntax are very much alike. Which is great, by the way.