At 11:44 PM +0100 7/4/10, Ashley Sheridan wrote:
On Sun, 2010-07-04 at 17:06 -0400, Paul M Foster wrote:
 > On Sun, Jul 04, 2010 at 11:43:59AM -0400, Al wrote:
 > > Seems like, from my preliminary Google searching, I should not waste
 > time with
 > the standard's way and just go straight to sending simple html pages
 > since all
> modern browsers handle it well. And, it appears to be the way web is going.
 > What are you folks doing?
 I use mutt for email, so I only see the text portion. That make me an
 anomaly. However, for example there are various listserv software that
 > will not allow HTML in emails.

 > Paul


One feature I've seen in some mailing list software is the ability to
track how people prefer their email formatted, so that you only send
HTML emails to those that want them, and text emails to those who prefer
that method. It's the best of both worlds I reckon, and one that is
likely to upset as few people as possible; at the worst they might
receive one email in a format they don't want before they change their


I agree with both Paul and Ash but for a different reason.

Receiving email is much like looking at web sites -- it's data provided from a server to an application to be shown to a user. In the case of web sites, html is provided to a browser and the browser presents the content to the user via the instructions provided by the html and others, such as css and javascript.

Unfortunately, if you've done any web sites at all, you know that not all (less than a score of them) browsers are created equal and while your web site may look great in your browser, it sucks in another. It takes a lot of work to make a web site look consistent on all modern browsers. Here's a little something I wrote about it:

Now throw on to this problem how hundreds of different email applications running under hundreds of different OS's (this includes hand held devices) handle html/css/javascript and you'll have an idea of the size of the problem of how to present data to the user via the user's device.

Sending HTML in email isn't the problem, but receiving and displaying HTML in email IS.

Simply put, there isn't a standard for sending/receiving email and while clients may want a pretty email to be sent to all their customers, they are clueless as to what their customers will actually receive.

Furthermore, there is considerable pressure by clients on developers to create the prefect email. Unfortunately, some developers succumb to the pressure (or they don't know any better) and create a send/receive that works for a special case, namely something sufficient for management to think the problem has been solved but it hasn't -- perhaps that's the reason why Adobe emails look so bad -- management still doesn't understand the problem and their developers either don't know any better, or are afraid to tell management the truth. But proof is in the pudding and while they may think the Emperor's new clothes are magnificent, they aren't.

My advice, send text! If you want the end user to see something, then send a link. But do not send HTML in email until every known browser conforms to W3C standards. At that point, then we can start working on hand-held devices to follow the standards as well. When that is finished, then we can consider sending something other than text in an email.




PHP General Mailing List (
To unsubscribe, visit:

Reply via email to