Jeff "Coding Horror" Atwood has fingered a particular sore spot for me in Web Development as Tag Soup:
"Tag soup" is his name for the ~~spaghetti~~perfectly valid stuff that inevitably occurs in server-side, tag-based languages. A typically ~~hideous~~perfectly valid example he shows is:
<h1>Archive for {{ year }}</h1> {% for date in days %} {% ifchanged %}<h3>{{ date|date:"F" }}</h3>{% endifchanged %} <a href="http://www.codinghorror.com/blog/archives/%7B%7B%20date%7Cdate:"m/d"|lower }}/">{{ date|date:"j" }}</a> {% endfor %}
Which blithely marries presentation (HTML), control (for loop), and domain logic (the ifchanged and link).
~~Tag soup is a big deal, and not just for aesthetic reasons....~~
I started to write a fairly extensive post explaining why it was a big deal to combine presentation, control, and logic, when I happened to remember that, while it's out of fashion, there's a perfectly valid architectural pattern that combines them.
The Presentation-Abstraction-Control architectural pattern stands in contrast to the more popular Model-View-Controller and related patterns. Where MVC could be said to embody the theme of "separation of concerns," PAC could be said to have the theme "Object, know thyself!" In PAC, an object knows everything there is to know about itself: it's data, it's behavior, and it's presentation/UI. If that immediately sounds unwieldy, let me reassure you that PAC emphasizes object graphs and hierarchies, so lots of presentation stuff is deferred to child objects.
For instance, the "tag soup" above might be a perfectly reasonable result of a call to a function Archive.renderChangedArticles() which, in turn, might be called from the renderArchivePage() function of the Blog object. While PAC may seem unusual for user-interfaces, it's similar to a common way of writing a custom XML serializer (that is, you define a Node toXml(Document doc) function on all your classes and let objects write what they know and defer the rest to their children objects).
The Visitor pattern or monkey-patching are alternatives to the direct writing of such functions inside a class. But still, the idea of not separating the concerns of rendering, control, and domain logic, is essentially "PAC"-ish. You can find support for this type of approach somewherein most tag-based libraries. But, of course, it's not about what's possible, it's about what is facilitated.
Do any tag-based languages or tools facilitate the PAC approach? Not that I know of. It would have to be a tool that looked "more" like an IDE (with all those tools for navigating objects and functions) than a design surface (since most rendering definitions would not be associated with the object that defines the \<html> root element).
Instead, we are pained by the output of tools that facilitate the cutting-and-pasting of tags to create an enormous drop-through imperative page (I'm looking at you, Dreamweaver!)