[thelist] HTML Email

[Ron Dorman]

James Parsons wrote:

>>Diane Soini wrote:
>>
>>    
>>
>>>I was asked recently for some help on some email marketing. The person
>>>was doing a somewhat complex layout in HTML for the purpose of sending
>>>by email. Problem is, I don't know anything about email clients and
>>>their ability to render HTML, so I wasn't sure about what you can and
>>>can't do. I looked on the web but had a hard time finding anything
>>>useful. Does anybody have any info about how you can write HTML for
>>>email, the dos and don'ts?
>>>      
>>>
>>Google for: email+html+AOL and read the info for AOL's html email. Make
>>your stuff fit that and all others will be handled. Do pay attention to
>>the 'multipart/alternative' content type and having plani text and html
>>in the same email so non-graphical readers will get the message too.
>>
>>Ron D.
>>
>>    
>>
>
>
>Mostly, I'd say DON'T send HTML mail. Not unless you're very very certain
>the recipients are going to welcome it. Some people, such as your's truly,
>absolutely do not want HTML email showing up their inboxes, even if it's
>something I've signed up for. HTML mail is instant anathema and I get very
>little of it that isn't just spam. If I look at the source code and it's
>evident they're using tracking gifs and things, then I get really annoyed.
>If it's HTML mail and it somehow makes it past my procmail system, it goes
>right in the trash bin, unread and unwanted and the company that sent it
>gets multiple black marks. Ezines & lists that, for some inexplicable
>reason, switch to HTML mail that do not have an option for plain text will
>be unsubscribed to. If there's no plain text option, they won't even get
>subscribed to in the first place. The only people who get to send me HTML
>mail without it going straight to the trash bin are those who, like clients
>and customers, are paying me. Fortunately, I don't have a lot of clients
>and customers who are all that big on HTML mail. They tend to be more like
>me in that respect.
>
>If one must, I would suggest that messages be sent in plain text with a
>link to an html version that's on the sender's website for those who like
>that sort of thing.
>
James,

While I may, or may not agree with you, that's a reason for 
"multipart/alternative" with text and html in the same email. If the 
user has set their preferences to "no html" (or an email client is not 
capable of html), the text message is delivered. I had to build email 
services for a client, no spam, only subbed recepients, with no 
indicators of recepients preferences. I am by no means an expert on the 
subject, but did have to deliver a solution to the client and read and 
learned enough to deliver.

I may be off base, but I think our jobs are to deliver a solution, as 
close to valid markup as possible, with as little of our personal 
opinions involved as possible, within legal and good ethical bounds. We 
should of course inform clients of pitfalls and disadvantages and our 
opinions of them in all honesty, but still deliver a solution within 
afore mentioned bounds.

Simply not delivering html emails is not a resolution or solution. Find 
a way to satisfy both ends (and the midde) of the preference bar and you 
have done well.

Ron D.