Hi,
sorry for the delayed issue. I was in Berlin last week at the wonderful
Beyond Tellerrand Conference. Most of the text has been ready for nearly 2 weeks. But my perfectionist self prevented me from htiting the send button. I wanted to share with you some behind the scenes info and walkthroughs of my updated
Email Layout Calculator. But alas, there are some bugs I want to fix first. So that will go in the next issue.
This issue focuses on
Inlining CSS - why, how, gotchas, and
CSS Inliners galore! Also I wanted to share some experimental code for a fluid grid that
can work in Gmail too.
If you have feedback or a particular Email development question, please
let me know - and maybe it'll end up in the next issue :)
|
I. Why Inline CSS?
|
Answer: Gmail.
Did you expect Outlook? Actually Outlook does a great job supporting included <style> tags. As an experiment, I created a quick email with no inlined CSS to see what it would look like:
|
Outlook renders fine without inlined CSS
|
As you can see, Outlook 2007 has no problem rendering an email without CSS. In fact, it's only Gmail that screws up the email. See the email previews for details.
|
For some variation, I tried to:
|
 |
style the <table> tag
|
|
style the <td> tag
|
|
style a <div> tag
|
|
throw a <div> between text within a <td>
|
|
So, to repeat: Why do we inline CSS? Gmail, not Outlook.
|
|
II. CSS Inliners
|
Many email developers prefer to write their inline CSS by hand. I am not one of them.
Advantages
One of the reasons I can code and iterate so fast on emails is because I use CSS inliners. That way I can write email html as I would for the web:
|
|
Use classes to keep design and components consistent
|
|
Leverage the power of SASS
|
|
HTML Markup that is readable
|
|
throw a <div> between text within a <td>
|
|
Disadvantages
But I understand why you would not use an inliner: it changes your code, often in ways that break your email:
|
|
by removing if mso comments that contain our Outlook wrapper tables.
|
|
by inlining included <style> tags, that are not supposed to be inlined.
|
|
by changing your Margin hack to margin (but I don't believe you should be using hacks anyway).
|
|
by combining multiple CSS property declarations into short hand - breaking layouts:
|
|
.example {
/* this works across all clients */
background-color: #111111;
background-image: linear-gradient(#111111, #222222 50%, #111111);
/* but this does not */
background: #ff0000 linear-gradient(#111111, #222222 50%, #111111);
}
|
|
Because Outlook does not understand linear-gradient, it ignores the entire background property, which means you do not even have a background color.
This is a problem. But this easily is fixable: we need a CSS inliner that respects our CSS code.
Gothcas: the Inliner Checklist
What does the right CSS inliner do? It…
|
|
does not change or adjust HTML
|
|
does not remove comments, especially. <!--[if mso]>
|
|
does not concatenate multiple CSS properties into shorthand
|
|
inlines specified styles, but not others.
|
|
includes specified styles, but not others.
|
|
Is there such an inliner? Yes.
Use Roadie
While editing this newsletter, I deleted several paragraphs and left this slide from my October 2015 RubySauna talk Mastering Email with Ruby instead:
|
CSS Inliners in Comparison: Styliner, Juice, Premailer, and Roadie
|
I have had to use all the inliners listed above in different client projects. Even without this experience, I recommend that you peruse the GitHub issues of each inliner. See what problems others have before you decide.
I use and recommend Roadie. It has just one open GitHub issue (at time of this writing), which in my opinion makes it the most stable. It does not have a web interface like Premailer (ca. 95 issues btw), which is probably why it is not as popular.
I have used Roadie for over a year now and it is by far the most consistent CSS inliner. If you're interested in a more in-depth comparison between inliners:
(CSS Inliner comparison starts at Slide 20)
|
|
III. Better Responsive Columns?
|
In this section, I want to share with you how to potentially make responsive columns that are also fluid on Android.
My Email Layout Calculator, uses a template to generate the appropriate <table> per columns. Each table starts like so:
|
|
<table width="100%" align="left" class="col" style="width:100%;max-width:{{ total }}px;">
|
|
Note: for code clarity, I have removed some non-essential <table> markup in this section.
|
4 Columns Diagram - Email Layout Calculator
|
Having max-width is necessary so non-Outlook clients have the property width.
But it is also less than ideal because Gmail on Android will limit the column to that pixel width, e.g. 250px and not show a column at 100% on mobile. This is really apparent when you have more than 2 columns.
Lately, I have been experimenting with:
|
|
<table width="100%" align="left" class="col" style="width:25%">
|
|
|
in combination with:
|
<style>
.col {
width: 100% !important;
max-width: 150px;
}
</style>
|
|
Because max-width is not inlined but included, it no longer applies to Gmail. And this still works in the most problematic email clients:
1. Microsoft Outlook 2007/10/13 seem to prefer the width attribute on the <table> tag over the inlined CSS property, even though it supports the CSS width property according to the Campaign Monitor CSS Support Guide.
2. Gmail Web prefers width:25% and aligns the columns side by side as expected.
3. Gmail on Android has full column width.
But…
Gmail on Android sometimes does not stretch <table>s to fill the device width. In my experience, this happens only if there is enough content. So depending on what you have in your columns, this solution might not work for you.
This technique is not thoroughly tested. If you try it out, please let me know how it works for you.
And with that, I hope you also enjoyed this issue of the Email Development Newsletter. Please forward it to friends and colleagues if you find this useful.
Greetings from Munich,
Julie
|
