Test email does not match CiviMail WYSIWYG editor

Question

We are building complex emails with a multi-column template. The geometry of the mailing looks good in the WYSIWYG editor, but when you send a test email, it looks different. Does anybody hear the same concern from users?

Answer 1

WYSIWYG is something of a misnomer; what-you-see is not really what-you-get. This is universally true whenever your editing environment is different from the final product, even going back to the print world— my bluesheet was always going to be slightly "off" compared to my proof. This is not specific to CiviCRM, but the inherent problems are exacerbated because 1) you are working in a web browser, and 2) your are trying to produce an email— and triply if you are trying to copy and paste from material prepared in a Microsoft Office, Adobe Creative Suite, or other desktop software.

Formatting-to-markup varies almost arbitrarily

The first issue is that the HTML produced by a Javascript WYSIWYG editor like CKEditor differs slightly from machine to machine. To repeat, not only will the appearance differ slightly from browser to browser (and browser version to browser version), operating system to operating system, and editor configuration to editor configuration, but the markup itself is different.

This happens because there is no standard way to translate "rich text" into HTML elements. Even with HTML5, each browser manufacturer interprets ContentEditable in its own way, and at its own success rate.

I tried copying and pasting the same text from an e-mail signature from Outlook 2013 into the same CKEditor-enabled form on the same site in four different browsers and got four different markup results when I view source:

Microsoft Edge

<p style="margin: 0in 0in 0pt;"><b><span style="font-size:10.0pt;font-family:
&quot;Arial Narrow&quot;,sans-serif; color:#1F497D">PUBLIC SECTOR</span></b></p>

Google Chrome

<p style="margin: 0in 0in 0pt;"><strong>PUBLIC SECTOR</strong></p>

Firefox Developer Edition

<p><strong>PUBLIC SECTOR</strong></p>

Opera 12

<p><strong>PUBLIC SECTOR</strong><br />
&nbsp;</p>

You cannot rely on a WYSIWYG editor to produce predictable HTML. End of story.

Email clients are weak at HTML, terrible at CSS

The next problem is that email clients do not interpret HTML and CSS as well as browsers do (Javascript, and often webfonts, are out of the question entirely due to security concerns). Cross-platform HTML emails are exceptionally difficult to produce. This is a top question in the manuals of every email provider from Litmus to SendGrid, and the raison d'être for companies like EmailonAcid and PutsMail.

The problem is exacerbated further because people can check their email in many different ways. For my various work and personal accounts, I use a combination of Outlook 2013, Rackspace webmail, other webmail (Gmail, Outlook.com, AOL, etc.), various mobile clients (iOS Mail, TypeMail, Gmail for Android), and even Trillian, and while as an IT worker I am an outlier in this regard, it wouldn't be unusual if many of your recipients checked email on a desktop client or webmail, an Android phone, and an iPad as my parents do.

Simplify your formatting

CampaignMonitor offers a well-maintained guide to CSS in email, showing how different email clients will mangle your CSS in different ways. Gmail, probably the largest and most popular webmail service, strips out quite a bit. Outlook, probably the most popular desktop client, doesn't support responsive layouts or most positioning. And these are relatively easy to get a hold of for testing— good luck finding a test suite for IBM Notes (neé Lotus Notes) or Novell GroupWise.

Therefore, the old advice still applies: the more predictably you want your emails to render, the more primitive your formatting must be:

1. inline CSS 2.1 only, and using only basic selectors
2. no HTML 5 elements
3. only basic text and font formatting, which means
   a. no positioning
   b. table-based layouts c. avoid padding or margin
   d. avoid floats
4. basic image handling
   a. no CSS background images
   b. specify pixel-based image dimensions

There are many guides available and many testing suites.

Suggested practices for CiviCRM

To mitigate the problems with HTML, I encourage authors to do the following:

1. Always provide a text version

For CiviMail, you have the option to include separate text and HTML input. There are people who prefer text to HTML for various reasons, but it also provides a mechanism for people with absolutely hopeless email clients to read the content.

2. Include the permalink to view the mailing as a web page

If anonymous users have the "view public CiviMail content" permission in your setup, you can include the token that provides a link to a web page version of your message. Then you can simply stick this link at the top of the header with the usual explanatory text, e.g. If you have trouble reading this message, visit XYZ to view it as a web page.

But I think the best advice I can give is to give up the desire to have total control over the end user's experience. Email was never designed for that, and there's nothing CivicRM alone can do to change the way the world consumes its electronic mail.

Answer 2

A solution that is round the corner (available now as alpha) is Mosaico integration with CiviCRM to give you a drag and drop template builder. Alpha-5 was released recently which works with 4.7