Part 1. Three errors designers make in their mockups because Drupal's theme system just can't do them well.

• moving something out of its vertical theming stack (why can't the node links be in the sidebar?)
• changing the formatting of a core element (why can't that blog archive block be a dropdown?)
• expecting visual consistency across different modules (why doesn't a node look the same as an item in a views list with exactly the same fields?)

Part 2. What's the underlying problem?

A failure of separation between data generation, representation, and presentation. I will show why the 3-part distinction, rather than the usual 2-part distinction (data + presentation), is critical to getting a grasp on how to make our good theme system great. I will explain why Drupal needs to formalize a data representation layer where the data format is independent of the desired markup.

Part 3. Why rule-based templating wins and why <font> tags suck.

I'll take a look at another project that got it right: Symphony (http://www.symphony21.com) uses XML and XSLT to separate its data representation from its data presentation. I'll then look at the main requirement of a solid templating system: rule based templating and compare it to the shift from presentation based markup to semantic markup in the XHTML/CSS sphere (e.g. why we stopped using tags). I'll examine the strengths and weaknesses of XML/XSLT and then run through other possible approaches to rule based templating that may fit Drupal's style and culture better.

Part 4. Where do we go from here?

An outline of the major direction the theme layer should take, and what we should expect to gain from such a shift:

• Greater theming flexibility
• Improved standardization of markup across modules
• Greatly reduced costs of having Drupal generate: RSS, RDF, XML, CSS,
  plain text, etc. etc. etc.

I will also take a brief look at how the main component building tools in Drupal blocks and panels will affect and be affected by a rule based system.