Answers.Body: <p><em>WYSIWYG</em> 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 &quot;off&quot; 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.</p>
  <h2>Formatting-to-markup varies almost arbitrarily</h2>
  <p>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 <em>markup itself</em> is different.</p>
  <p>This happens because there is no standard way to translate &quot;rich text&quot; into HTML elements. Even with HTML5, each browser manufacturer interprets ContentEditable <a href="https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480#.x1qd4y1xy" rel="noreferrer">in its own way</a>, and at <a href="http://www.browserscope.org/?category=richtext2&amp;v=top" rel="noreferrer">its own success rate</a>.</p>
  <p>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:</p>
  <p>Microsoft Edge</p>
  <pre><code>&lt;p style=&quot;margin: 0in 0in 0pt;&quot;&gt;&lt;b&gt;&lt;span style=&quot;font-size:10.0pt;font-family:
  &amp;quot;Arial Narrow&amp;quot;,sans-serif; color:#1F497D&quot;&gt;PUBLIC SECTOR&lt;/span&gt;&lt;/b&gt;&lt;/p&gt;
  </code></pre>
  <p>Google Chrome</p>
  <pre><code>&lt;p style=&quot;margin: 0in 0in 0pt;&quot;&gt;&lt;strong&gt;PUBLIC SECTOR&lt;/strong&gt;&lt;/p&gt;
  </code></pre>
  <p>Firefox Developer Edition</p>
  <pre><code>&lt;p&gt;&lt;strong&gt;PUBLIC SECTOR&lt;/strong&gt;&lt;/p&gt;
  </code></pre>
  <p>Opera 12</p>
  <pre><code>&lt;p&gt;&lt;strong&gt;PUBLIC SECTOR&lt;/strong&gt;&lt;br /&gt;
  &amp;nbsp;&lt;/p&gt;
  </code></pre>
  <p>You cannot rely on a WYSIWYG editor to produce predictable HTML. End of story.</p>
  <h2>Email clients are weak at HTML, terrible at CSS</h2>
  <p>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 <a href="https://litmus.com/help/email-clients/rendering-engines/" rel="noreferrer">Litmus</a> to <a href="https://support.sendgrid.com/hc/en-us/articles/200184928-HTML-Rendering-The-Do-s-and-Dont-s-of-Cross-Platform-Email-Design" rel="noreferrer">SendGrid</a>, and the raison d'être for companies like <a href="https://www.emailonacid.com/" rel="noreferrer">EmailonAcid</a> and <a href="https://putsmail.com/" rel="noreferrer">PutsMail</a>.</p>
  <p>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.</p>
  <h2>Simplify your formatting</h2>
  <p>CampaignMonitor offers a well-maintained <a href="https://www.campaignmonitor.com/css/" rel="noreferrer">guide to CSS in email</a>, 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.</p>
  <p>Therefore, the <a href="https://www.adobe.com/devnet/archive/dreamweaver/articles/html_emails.html" rel="noreferrer">old advice</a> still applies: the more predictably you want your emails to render, the more primitive your formatting must be:</p>
  <ol>
  <li>inline CSS 2.1 only, and using only basic selectors</li>
  <li>no HTML 5 elements</li>
  <li>only basic text and font formatting, which means<br />
  a. no positioning<br />
  b. table-based layouts
  c. avoid padding or margin<br />
  d. avoid floats</li>
  <li>basic image handling<br />
  a. no CSS background images<br />
  b. specify pixel-based image dimensions</li>
  </ol>
  <p>There are many guides available and many testing suites.</p>
  <h2>Suggested practices for CiviCRM</h2>
  <p>To mitigate the problems with HTML, I encourage authors to do the following:</p>
  <h3>1. Always provide a text version</h3>
  <p>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.</p>
  <h3>2. Include the permalink to view the mailing as a web page</h3>
  <p>If anonymous users have the &quot;view public CiviMail content&quot; 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. <em>If you have trouble reading this message, visit XYZ to view it as a web page</em>.</p>
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-26T23:28:18.973Z
Answers.Text: awesome response.
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-26T20:34:35.683Z
Answers.LastActivityDate: 2016-05-26T20:34:35.683Z
Answers.LastEditDate: 2020-06-17T09:00:50.810Z
Answers.UserDisplayName: choster
Answers.Body: <p>A solution that is round the corner (available now as alpha) is <a href="https://civicrm.org/blog/parvez/a-new-beginning-for-civimail" rel="nofollow">Mosaico integration with CiviCRM</a> to give you a drag and drop template builder. Alpha-5 was <a href="https://github.com/veda-consulting/uk.co.vedaconsulting.mosaico/releases" rel="nofollow">released</a> recently which works with 4.7</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-26T23:26:20.240Z
Answers.LastActivityDate: 2016-05-26T23:26:20.240Z
Answers.UserDisplayName: petednz - fuzion
Body: <p>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?</p>
  
Tags: <civimail><ckeditor>
Title: Test email does not match CiviMail WYSIWYG editor
ThreadText: # Test email does not match CiviMail WYSIWYG editor
  
  (Asked by: username_0 on 2016-05-26)
  
  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?
  
  **Tags:** civimail, ckeditor
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2016-05-26. Score: 8
  
  *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](https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480#.x1qd4y1xy), and at [its own success rate](http://www.browserscope.org/?category=richtext2&v=top).
  
  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](https://litmus.com/help/email-clients/rendering-engines/) to [SendGrid](https://support.sendgrid.com/hc/en-us/articles/200184928-HTML-Rendering-The-Do-s-and-Dont-s-of-Cross-Platform-Email-Design), and the raison d'être for companies like [EmailonAcid](https://www.emailonacid.com/) and [PutsMail](https://putsmail.com/).
  
  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](https://www.campaignmonitor.com/css/), 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](https://www.adobe.com/devnet/archive/dreamweaver/articles/html_emails.html) 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.
  
  > **Comments:**
  > **username_2**: awesome response.  
  
  ---
  
  ### Answer by username_2 on 2016-05-26. Score: 2
  
  A solution that is round the corner (available now as alpha) is [Mosaico integration with CiviCRM](https://civicrm.org/blog/parvez/a-new-beginning-for-civimail) to give you a drag and drop template builder. Alpha-5 was [released](https://github.com/veda-consulting/uk.co.vedaconsulting.mosaico/releases) recently which works with 4.7
  
  
  ---
  
  