Over at about:cmlenz, Chris discusses his thoughts on my previous article wherein I compared Genshi (and other XMLish template engines) to PHP. To be fair, the comparison was a bit tongue-in-cheek since most of my complaints about PHP relate to its use as a programming language, not as a templating engine, but Chris makes a key point that I think is worth addressing:

At least with Genshi and Kid, that “ugly thing to describe web pages with” is pretty much just XHTML. And that, of course, is a feature. For a web developer, reading and writing HTML (as well as CSS and Javascript) is at the core of any front-end work. I don't want a template system that tries to hide the HTML from me; rather, it should enable me to just take some HTML and hook it up to server-side application code.

This seems like a reasonable enough position. However this brings me back to a simple point: a document is independent of the particular syntax used to describe it. Whether XHTML, Latex, PDF, Postscript or whatever, it's the document that matters, not the particular syntax. XHTML is simply one more in a long line of machine formats for describing a document. And this is key. XHTML is not the document. It's a description of a document. Further, XHTML is not special. The only thing that sets XHTML apart from, say a binary Word document is the fact that it's reasonably parsable in its raw form by humans. This hardly qualifies it as an optimal representation for hand manipulation. The most compelling reason for using XHTML today is that everyone else does it (and in some cases, this is in fact a valid argument).

The argument that "I don't want a template engine that tries to hide the XHTML from me" reminds me of back when people argued against high level programming languages in favor of assembly language because HLL's moved them "too far from the machine". For most programmers, the machine doesn't matter. It's the end result that they care about. I feel much the same way about document-generation on the web. The fact that XHTML happens to be the language that browsers currently speak means little to me aside from the fact that I need to somehow feed it to them in order to retrieve my desired document. The plethora of tools for assisting with this suggests that I'm not alone in this desire. Some people actually use tools such as Dreamweaver exclusively for this task and never bother to learn the ins and outs of XHTML. Of course, as a programmer, this option isn't really available to me since I do need to integrate with a backend application (and seeing the output of some of this software discourages using it seriously anyway), but that doesn't mean I have to do it the absolute hardest way possible simply because the easiest way doesn't yet exist.

Also, to be accurate, Breve doesn't "hide" the XHTML, it simply gives you a shorter, cleaner way of writing it. What's the difference between having a vi macro or autocomplete in your editor or having what amounts to the same thing in your template engine? Breve is a shortcut for writing XHTML just as much as having a macro in your editor is.

Talk to anyone who does much XHTML editing and you'll undoubtedly get a laundry list of tools and macros they've written or collected to ease the pain of writing markup. Ask yourself this: if it weren't reasonable to write Python code without extensive help from editing macros and validators, would you still be inclined to use it? Pylons and Rails both include a bunch of "web helpers" to help reduce the need to write markup. My question is, why not just follow this to its logical conclusion and make your entire template engine a "web helper"?

My point in comparing XML-oriented template engines with PHP was not about how PHP is abused, but rather how it mixes two unrelated syntaxes together in a eye-straining mess. XML-based template engines are no different. XHTML is ugly all on its own. There is absolutely no way to make it prettier by stirring in another syntax.

My work on Breve has revealed more dark corners of the web than I thought I ever wanted to know.

Breve is, at its heart, an XML-generation engine. The fact that it can output HTML and that doing so is its primary purpose is almost incidental, really. What this means is that Breve happily outputs things like <div /> which is logically sound, but technically incorrect.

Now, in a previous, happier life I was blissfully unaware that not all elements can be self-closing in XHTML, especially since such tags will even validate in the W3C's own validator. I ran across the issue when Breve output something similar to the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
           Strict//EN" "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
  </head>
  <body>
    <div />
    <div>test</div>
    <div />
  </body>
</html>

Now on the surface, this looks fine. However, this is how Firefox rendered it:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
           Strict//EN"  "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
  </head>
  <body>
    <div>
      <div>test</div>
      <div></div>
    </div>
  </body>
</html>

I spent about an hour trying to figure out what I was doing wrong, changing doctypes, adding meta tags, etc. As it turns out, I was missing a key element: the HTTP header "text/xml". Now, I didn't think I was missing it, since I'd tried setting that via a meta tag to no avail. Luckily someone on #firefox pointed me to this bug report.

The short story is that there is no practical way to specify that an XML document is, in fact, XML from within the document itself. You must configure the web server to output the proper headers.

The longer story is that I modified Breve to only output self-closing tags for a small subset of XHTML and all is well (except for my faith in people who write RFC's).