This site’s design is only visible in a graphical browser that supports web standards, but its content is accessible to any browser or Internet device. | WHY WE DO THIS

   OrderSomeWhereChaos

Tips for Sending HTML Mail

I don't wanna, but I gotta...

Don't send HTML mail. Just don't. Just say no. For every day usage, there is no reason to use HTML formating in e-mail. Generally speaking, HTML mail is abused, wasting drive space and bandwidth, with no advantages in actually communicating. HTML mail to mailing lists often get in the way of others' use of the list, particularly when people are subscribed to digest versions. (Serious personal pet peeve here. Watch out.)

That said, sometimes you're ordered to produce HTML mails for marketing or other communication needs. Newsletters that people subscribe to can have plain text versions and HTML sent to them. However, here are some guidelines for creating these HTML-enabled layouts. These are tried and true guidelines have been hard learned through trial and error.

  • HTML support can never be assumed. Plain text e-mails is the only perfect method of sending e-mail. All HTML mails should be sent as "multi-part MIME" with a text/plain section preceding the HTML section.
  • Simple Layouts. All HTML mail layouts should be kept as simple as possible. If a design can be kept to a grid, and specifically, set on a white background, the mail will appear more consistent across clients and platforms.
  • Use HTML 3.2. Many mail clients are far behind browsers in terms of rendering capabilities. HTML 3.2 is the most consistently support HTML standard.
  • Use the doctype for HTML 3.2
  • No CSS. CSS support is very erratic.
  • No JavaScript. In addition to poor cross-client support, this will get caught by many spam filters.
  • DIV tags are used only for centering content with align=center attributes. CENTER tags could also be used.
  • Use tables to structure layout rather than CSS-P or other DIV-based layouts.
  • Avoid the use of ROWSPAN attributes in tables. Display of these layouts is erratic.
  • NEWEST RULE: When placing an image in a table cell, make sure there is at least two images, either next to each other, or stacked using a BR tag. (OS X.2 Mail.app bug: When a table cell has only one image, the cell will have more than 1 px of vertical spacing on each side of the image. Placing a second image of any size will sidestep this bug.)
  • Look to use BR tags to note line endings rather than P tags. BR tags are generally more consistently rendered. Various mail clients render the spacing for P tags with different margins.
  • Mail for AOL, should be built specifically for AOL and tested in each AOL client version to confirm operation.
  • If a domain is known to be a web-mail domain (mail.yahoo.com, hotmail.com, etc) mail can be customized to work with the latest version of the mail rendering there.

There are some files that have been helpful for me. It's a Perl CGI that sends an e-mail from raw text, plus two text files that are 1) the headers and first part for a MIME mail and 2) an HTML file that is sent along with it.