Beneath the deceiving surface, Magento manages email templates about as effectively as an addict manages withdrawal. Here’s a generalized list of the problems with creating emails for Magento based on the core functionality in 1.3.2.

• Previewing a template doesn’t serve any purpose, due to variable data not being displayed as dummy data. This often removes tables entirely and gives a false idea of what it will look like when sent.
• All templates are coded in an html format. They are then imported to Magento manually by the user, and do not dynamically reflect the content in the original html templates. This means there are two versions of the same template in Magento; one in the database and one in the file tree while neither talks to the other.
• After saving a template to the database from an html version, Magento cannot manually re-import the html to the database. It must be meticulously edited by hand in the admin panel, or deleted entirely and remade.
• There is no mass theme handler for what borders the content. Which is to say that if you want to change the footer text of your email, you must either delete all templates and remake them, or go into all 28 database entries through the admin panel and change them, or something equally ridiculous.

These are the main points of why Magento handles email like a bull in a china store. A better work flow would be to dynamically call to the html documents when an email is sent, possibly caching these files but not requiring code duplication. This means one edit per template instead of two. Additionally, create a theme XML akin to the store, which dynamically is called to when emailing. This way if the background color in the email needs changing across the board, it can be edited in one place. Finally, if an email needs an entirely different theme, create an exception tool on the Transactional Emails page where the hand coding can serve a purpose.

This is but one example of why Varien and Magento are painful to work with at best, and why making an open source cart that depends on a community to install core functionality is something to be avoided entirely.

That being said, I recently was informed my client needed updates to his layouts for shopping cart generated emails. To compare, a client asking me to do this is akin to me asking you if you know how to drive a car, and then giving you a road with nails and other deadly hazards while curious why you hesitate after you told me you knew how to drive. I can code an email, I don’t want to code it to comply with every mail client as it is again likened to running over every hazard on this road and trying to get to the goal in one piece.

This time consuming process is worlds worse than working around IE6 bugs, due entirely to the fact that IE6 has workarounds. Sure it does some funky things, but with a little push it does what it’s told. Gmail, on the other hand, gives the finger if inline CSS isn’t used, which means functionality like :hover cannot be implemented. This means that a nearly 10-year-old browser has more functionality than one of the largest mail clients today. Instead of pushing for new standards, Google created Wave which has no place in the majority of large corporations which don’t have the time or money to re-educate their pool of employees in an entirely new system while email works well enough.

Outlook, on the other hand, removed almost all CSS positioning functionality (aside from z-index) because, quite simply, it worked better for them (this article is 3 years old, and zero progress on Microsoft’s front). Microsoft touts itself as being innovative, yet with backwards progress such as this it’s no wonder there is little belief in this claim.

In short, there is no good reason for this removed functionality. Another example is that of Gmail, Outlook and a plethora of other clients removing the ability to add a background image. One could say security, one could say simplicity, one could say a lot of things. What it comes down to, unfortunately, is archaic systems that are not interested in pushing the envelope with the real meat of the system.

With browsers rendering just about anything under the sun in this day and age with little sweat, there is no reason to continue to stymie CSS functionality in emails.

This site is run entirely off of WordPress, which so far I am more than happy with. Somehow I expect this to change as well, based on my past experience with open-source CMS.