About the
Email Standards Project

The Email Standards Project works with email client developers and the design community to improve web standards support and accessibility in email. Read more »

Blog Archives

Blog Categories

RSS Feed

ESP Blog Feed

Recent Entries

Yes, you should get plain text too!

Posted by Mathew Patterson on December 5, 2007 in

Apparently we have not made this clear enough yet, so I wanted to say it explicitly:

Everybody should get the choice to receive HTML or plain text

If you personally prefer text-only email, you should always be able to set your email client to show plain text, and all your newsletters should a have plain text alternative for you to read. We totally agree! The Email Standards Project is trying to improve the rendering of the HTML portion of the email, not to get rid of the text portion, so there is no need to worry.

16 Comments so far

Nathan said...

Well Said,

I personally prefer text only, but all of my clients what to send HTML, so in reality it really makes no difference what I like, they are the ones paying for the time it takes to make an HTML email work, not me.

I’m all for the project, it’s a great initiative and to all the people who don’t like HTML in email, don’t worry about it, just set your email client to show text only… problem solved.

I’m whatching this project very closely, good work people.

Cheers.

Posted 6:09 pm on 05 December 2007 - #1
Smruti Ranjan said...

User can have preference on what type of email he wants to send, but how will one control what kind of email he wants to receive.One might loose information, if you always try to display the plain text part of the mail, for every mail.

So, I think this needs more preference, like only newsletters from specific receivers.

Also, RFC says to render the best part in an email.

Hence, i think its always a good idea but not a complete solution to the problem.

Posted 7:37 pm on 05 December 2007 - #2
PJ said...

The problem being we tend to see our biggest sales from HTML emails. However I noticed an increasing trend of people reading email on blackberries and mobile devices. It’s a good practice to include some more evolved text information in your HTML emails just in case this happens.

Posted 3:50 am on 06 December 2007 - #3

Thanks guys - although I want to point out that sending a plain text alternative is not something we should do ‘just in case’, it is something we should send as an equally well thought out alternative, for people who prefer it.

Posted 6:46 am on 06 December 2007 - #4
Jeff said...

I think this post is scratching at a good topic - Multipart Alternative emails. My experience is finding that most email clients don’t support allowing a user to change their preferences from receive HTML part or receive Text part.

I think an entire project could be dedicated to the industry adopting end user support for setting preferences regarding multipart alternative emails.

While my research is not exhaustive… here’s my scratch the surface findings:

*Thunderbird does an excellent job.
*GMail only renders the HTML, but allows a user to view the original un-rendered message, but not the text part by itself.
*I believe the latest version of Y!mail works the same as G!.
*Outlook 2003 only renders the HTML - but has an option where a user can choose to view as text, which rather than display the text part, the app displays the HTML source as text *ugly*.
*Outlook 2007 appears to have done away with this option, only rendering the HTML part.
*Lotus (I believe I looked at 7) appears to have a setting on the server level and not the client level.

Posted 9:14 am on 06 December 2007 - #5
Dan Kubb said...

I’m glad Jeff brought up Multipart Alternative emails because I have a couple of questions about this.

I’ve read alot of recommendations from alot of people that you should send both plain text and HTML in the same email, something which I actually make a point to do.  I even put the plain text part first in the message body, so if there’s a problem parsing and the message is garbled on the client’s end, that a plain text version is “above the fold”.

I’ve even considered using the “preamble” feature in Mime (see RFC 1341) to include text to explain to people with low capability email clients how to re-request the email as plain text only.  (I’d love to hear some feedback from people on whether this is a good idea or not)

Recently I did a bit of research to verify if what I’m doing is the “best” way and I came across some recommendations to not bother sending multipart emails because it can increase the message body size increasing the likelihood that it is filtered or blocked.  The articles I read also said that the number of clients that can’t display at least a subset of HTML is so tiny that it does more harm than good to send multipart.  Their suggestion was just provide to a way for the end-user to set their HTML/Text preference when they provide their email address and/or allow them to change their preferences at any point.

What are your thoughts on this, and is there any “best practice” for dealing with this?

Posted 10:06 pm on 08 December 2007 - #6
Flumpy said...

The idea with Multipart is that both HTML and Text versions are sent in a single message, and that the end-user’s email client’s preferences determine which version they see (Note: both parts are still delivered to the user). In practice though, very few users change their email client’s default preferences and in reality it’s usually only the tech-savvy, HTML-loathing users who make the conscious choice to receive Plain Text format emails. However, with more and more users receiving email on the move, via handhelds, PDAs and other wireless portable devices, I think the Plain Text format is still very relevant.

Benefits of sending Multipart:
* Both HTML and Plain Text and sent in a single send
* User’s preferences determine which version they see
* May help increase deliverability slightly

Downsides to using Multipart:
* Users have to download the whole Multipart message, although they will normally only view one part of it. (This is most relevant to plain-text email users who’ll be downloading extra code for the HTML version, which is normally heavier - although I don’t think any external content (e.g. images) would be downloaded unless the HTML part is displayed)
* Although the MIME Mutlipart specification has been around for a long time, some email clients may not be able to handle the Multipart format properly. (Although I haven’t had the time to research or test this recently, I expect problem candidates are clients with poor HTML support like Lotus Notes).

Jeff: Yes, it looks like Outlook 2007 has removed the option to force the receipt of emails in Plain Text format. In Outook 2003 This used to be under Options > Preferences > Email Options. Very annoying!

Dan: The preamble is a great idea, but I’m not sure how well supported it is. I don’t think the extra ‘weight’ of sending Multipart is necessarily a deliverability hindrance; however, as with any email, if the HTML part is very large, it may trigger certain spam-filter flags. A good balance of real text vs images in your HTML format is probably more important than the overall message/file size of the Multipart message.

Allowing users to set their mailing preferences via your site and then sending two seperate broadcasts (one HTML, one Text) is probably the most robust and reliable way to deliver the two formats, but it also requires increased time to manage two lists/databases, two lots of unsubs, resends etc.

Posted 10:22 pm on 10 December 2007 - #7
Roberto Estaogle said...

The person who invented HTML email and email attachments should have been ripped off teeth one by one and then shot, hung, poisoned and fucked with a piledriver and 16 feet of curare-tipped wrought-iron fence and no lubricants.

Posted 12:15 am on 11 December 2007 - #8
Flumpy said...

Roberto: I used to hate HTML email, too, so can sympathise slighly - but it’s here to stay so fing and blinding isn’t going to change anything, unfortunately. The arguement against attachments, however, is a non-starter - email simply wouldn’t be the ubiquitous tool it is today without the ability to attach files, documents, pictures etc.

The most important thing we can do now is push the software giants to support good, standards-compliant emails (both HTMl and Plain Text) and to increase security for end users without compromising the freedoms we all enjoy.

Posted 12:46 am on 11 December 2007 - #9
Mark Wyner said...

Thanks for your valuable contribution, Roberto. I’m curious what your stance is on child molesters and serial rapists.

--/ RE: MULTIPART /--

One should use multipart messages to help ensure successful delivery of an email which is also readable. Consider the following scenarios:

* Many less-than-savvy people sign up for email newsletters and don’t realize their email clients don’t support HTML.
* Many savvy people intentionally sign up for HTML emails knowing their email clients support HTML, but then read them from a mobile device while on the move.
* Many people have heavy spam filters. Multipart messages (including standards-based HTML) help the code-to-content ratio; favoring content of course.

--/ RE: PLAIN-TEXT SEGMENTS /--

I believe we should give as much attention to the plain-text component of a multipart message as we do to the HTML component. Plain-text emails can be “designed” to a certain degree. Creative formatting of headlines/subheads, lists, etc. can make a plain-text email really sing.

With HTML, we have an arsenal of tools to help us emphasize specific parts of a message. While plain-text formatting is limited, a little creativity and attentive consideration can go a long way. And for recipients who receive the plain-text segments of a multipart email, this can have a huge impact on the message we’re trying to convey.

Posted 4:03 am on 12 December 2007 - #10
Flumpy said...

Mark: Totally agree that as much care should be taken to format the plain-text version. I’m constantly amazed at how poorly some of my company’s clients deal with this side of things.

Tips for plain text email formatting
------------------------------------
* Keep your line length to around 67-71 characters, as this is the optimum for a range of email clients
* Don’t use TABS for layout as they are treated differently by email clients. Some email clients will collapse TABS, others will display them at different lengths. Since most email clients use a fixed-width font to render plain-text emails, you can use mutliple spaces for layout purposes.
* Ensure your plain-text editor saves your files as PC/Mac ANSI (some people use UTF-8 but this isn’t as well supported in email clients)
* Be aware that the special character range is very limited - many characters supported under HTML encoding mechanisms are not supported in plain-text. Generally, when you copy and paste your copy from, say, Microsoft Word, into your text-editor, unsupported characters will show up as a solid black character. Simply overtype these and replace with whatever works for you as an equivalent from the available character list.

Posted 10:37 pm on 18 December 2007 - #11

Hi All, just been pointed at this site by a friend and very glad to see this particular thread as well as a general standards based approach. I’m a long time user and fan of the Pegasus email client and I must confess that my thoughts on HTML email have often echoed Roberto’s. (As a CSS evangelist I’d also add in the guys that developed IE6!!)

However it seems we have lost that particular battle probably because the marketing people want the flashiness of HTML for their email campaigns. As an SEO as well as a web designer I can understand that although I will always want to read my email in plain text unless a complete overhaul of the system comes to pass. To me Multipart is essential if we are to retain any sort of universal access to email. If I receive HTML-only it gets deleted unread.

Will be watching this forum with interest.

Cheers

Posted 2:18 am on 25 April 2008 - #12
SEO Expert said...

Yes, that’s totally right… actually every email message sent should be based on multipart mime types text/html, as a lot of people including me do check their email accounts using a wap device like blackberry!

Posted 11:41 pm on 24 May 2008 - #13

Good point, i know from several email clients that i have used that html email often either fail to load or go into the junk folder which i why i usally just go for plain text option.

Posted 10:00 pm on 21 June 2008 - #14
Anders said...

Everybody should get the choice to receive HTML or plain text - Golden words, 95% of my mail is plain text!

Posted 7:34 pm on 26 June 2008 - #15
Replica Gear said...

I do agree, it should be the users choice to decide how they want to receive/view their email.

Posted 2:22 pm on 28 June 2008 - #16

Post a comment or leave a trackback


 (?) This is just to check you're a human and not a spambot.