![]()
|
|||||||||||||||||
Overview As of Form Tools 1.2.0, you can now fully customize the content and appearance of emails sent to administrators and users. While this provides you with a great deal of control, it's easy to be misled into thinking the CSS you enter into your templates will render the emails to look the same by everybody. Unfortunately, it's not half so simple... This short tutorial explains the issues involved in using CSS in your email templates: what hurdles you'll need to overcome, a few suggestions to follow to ensure your email templates look consistent across email clients, and some helpful links for further reading. Rather than delving too much into particulars (namely, which CSS properties/selectors work in which client) I merely wish to outline the issues here. The articles listed below in the References section cover the details in more depth than I could ever hope to do here. The Wonderful World of Email Clients There are literally hundreds - if not thousands - of programs that let you access and read your email - these are known as "email clients". Generally speaking, email clients can be split into two types: desktop applications (e.g. Outlook, Thunderbird, Eudora) and web-based clients (e.g. Gmail, Hotmail, Yahoo). Virtually every client has its own way of rendering HTML and CSS in emails, but a number of similarities exist based on the type. So let's start there. Web-based Clients By definition, a web-based client displays a emails from within an webpage. As such, creators of web-based clients stumbled across a problem: how to prevent styles within HTML-formatted emails from conflicting with the styles used to render the email client itself. Generally speaking this problem has proved intractable, and the commonest solution is to strip out a lot of the CSS. Because of this, Gmail, Hotmail, LiveMail and Yahoo are considerably more restrictive than desktop applications in what CSS is rendered. Desktop-based clients Desktop clients have, on the whole, better support for styles in emails - mainly due to the environment in which they are read. For PC, Outlook, Outlook Express and AOL all use Internet Explorer as the rendering engine, so if you can write for one of those, the others will work too. For Mac, Mac Mail and Entourage offer better support (see Campaign Monitor findings) Eudora, on the other hand has practically no support for CSS. A Few Guidelines Here a few things to keep in mind when you're neck-deep in developing your email templates. Know your Audience If your form are submitted by members of the public, you can guarantee that they will be reading their emails on some of the worst email clients imaginable (Sod's Law), so Keep It Simple, Stupid! (the KISS principle). If you're not using user email notifications or if you know the users will be reading the email on a specific email client (e.g. Form Tools is being used within a company's intranet), then you may be able to develop your email templates with that in mind. Hard and Fast Rules Here's a few rules to keep you on the straight and narrow. And yes, I realise that some are contradictory: welcome to developing on the web!
Test test test! If time permits, test your email templates in as many email clients as you can. Send them to other people and get their input. Annoy your friends, relatives, member of parliament. If you're extremely particular about how your emails are going to look, this step is imperative. References Each of the following articles is well worth reading. The Campaign Monitor link contains a handy downloadable PDF of results for CSS support in many common email clients.
|
|||||||||||||||||