Make rendered email better for Outlook recipients

[mvhenderson]

Using the Chrome plugin with Gmail and sent emails look great on any mail client. However, when a recipient replies or forwards a message with code-block the rendering is all messed up:

This seems to always happen when the recipient is using any version of Outlook.

[adam-p]

I'm co-opting this issue and turning it into a more general "figure out how to make MDH-rendered email not look like crap for Outlook recipients".

Other reports...

Screwed up newlines in code blocks -- where I delved into the problem and found no solution: https://groups.google.com/forum/#!searchin/markdown-here/outlook/markdown-here/3VxiCMqGGrc/Mbj-Arq0hQwJ

Disappearing lists: https://groups.google.com/forum/#!searchin/markdown-here/outlook/markdown-here/QGKfIGnUIZ0/SB0ATefYlNEJ

[adam-p]

Some of the info here will be useful: https://github.com/adam-p/markdown-here/wiki/Development-Notes#the-limitations-of-email

[adam-p]

Well, I figured out one bizarre trick for getting lists to display properly in Outlook. From the following rule in your MDH "Primary Styling CSS", remove the ul, ol:

-table, pre, dl, blockquote, q, ul, ol {
+table, pre, dl, blockquote, q {
  margin: 1.2em 0;
}

The problem seems to be the explicit 0 left margin. I think the bullets are actually there, but pushed off to the left. This is what happens with margin-left: 10px:

NOTE: <style> blocks work in Outlook, but not in Gmail. Nor, I think, most webmail (ref?). (I mean, "work" when reading the received email.)

One thing that works is overriding the margin style in a style block:

<style>
  table, pre, dl, blockquote, q, ul, ol {
    margin: 1.2em 4em !important;
  }
</style>

Using initial or inherit inline work, but using them in a style block in the email does not work -- I suspect initial and inherit are simply ignored altogether.

NOTE: Microsoft Outlook (well, Office) has some specific mso-* styles. Here's a list.

A more promising approach is to use a Microsoft Office-specific style in a block:

<style>
ul, ol {
  mso-para-margin-left: 20;
}
</style>

...It works with the default MDH styles!

I picked 20 based on nothing but "it's probably large enough" -- I'm not sure what the "best" value is. I'm also not sure if mso-para-margin-left is "best" -- I just tried a couple things and it worked. But I'm not going to test all million possible styles.

NOTE: Inline styles that the current browser (Chrome, say) can't recognize -- like mso-* -- will not end up in the sent email.

That means we really have no choice but to use a style block.

NOTE: Conditional HTML -- like <!--[if gte mso 9]> -- will not be retained in the sent email.

NOTE: <style scoped> is not supported widely enough to use.

That means that if we want to start using style blocks, they will be affecting the entire webmail page. And that means that we had better qualify our selectors so they only affect our content:

<style>
.markdown-here-wrapper ul, .markdown-here-wrapper ol {
  mso-para-margin-left: 20;
}
</style>

NOTE: If that style block is inside the <div.markdown-here-wrapper> wrapper, then the .markdown-here-wrapper selectors will not work.

That means that either the style block needs to be outside our wrapper, which is somewhat distasteful, or we need to do something like... a) add an inner wrapper, b) give every MDH element a class attribute. Neither of which is great.

So, what we need to do (at least):

• Figure out where to put the style block.
• Add the style block.
• Figure out the best way to qualify our selectors.
• Figure out the "correct" value for "20".
  • Maybe 36.0pt? This is the margin-left value used by Outlook for its p.MsoListParagraph element.
• Add the style.

[adam-p]

More notes:

View in external browser

In the style reset CSS in this HTML email boilerplate there is an interesting line that causes Outlook to show a prompt to open the email in a web browser. (Let's ignore that I get that prompt whether or not I have that style in place.)

/* Force Outlook to provide a "view in browser" menu link. */
#outlook a {
  padding:0;
}

When I open the MDH sample MD in the external browser, the styling is great, but the extended characters are mangled (where they aren't when viewed in Outlook). So I'm not sure that's a win. Plus, requiring recipients to open all their correspondence in an external browser seems ridiculous.

Sending from Thunderbird

Thunderbird has more control than the webmail clients over what HTML/CSS is included, so we may be able to have a <html> tag, etc., in that case. On the other hand, I detest that much platform-specific special-case code. Maybe the extra tags could be included on all platforms, and we'll let the webmail clients throw them away.

Non-email

Don't forget about Evernote, Blogger, etc. Their behaviour regarding <style> blocks, etc., might be different than the webmail clients. Don't screw them up.

[neilmayhew]

@adam-p You don't appear to have addressed the issue of code blocks. They're working OK for my Outlook recipients, except the border is applied to every line instead of the whole block. I think this is because Outlook's internal text model works at the paragraph level, rather than the block level. In the HTML that gets sent back to me when quoting my message in a reply, each line of the code block is now a separate <pre> element, with the same attributes as the original <pre>, including the border.

[adam-p]

I have co-opted this issue for Outlook display stuff in general.

Above I said:

Screwed up newlines in code blocks -- where I delved into the problem and found no solution: https://groups.google.com/forum/#!searchin/markdown-here/outlook/markdown-here/3VxiCMqGGrc/Mbj-Arq0hQwJ

And that's pretty much where the code thing stands. What you see with the multiple <pre> elems corresponds with my observations in that post. (Though I don't know why it's happening. You could be right. But I'm not sure how to turn that into something to try.)

...

And then I sat here for a while, considering that I know more about Outlook nonsense now than I did before. So I came up with another approach: Just remove the code background and border to hide the fact that <code> elems are being treated as inline rather than block.

As we learned above, Outlook will obey <style> blocks, but webmail won't , so we can use it for Outlook-specific rules. Like so:

<style>
  .markdown-here-wrapper pre code {
    border: none !important;
    background: transparent !important;
  }
</style>

NOTE: Outlook ignores inline styles with the !important declaration, but obeys them in <style> blocks. (ref) This can be confusing during testing.

That might make coloured text illegible, so we should probably get rid of the syntax highlighting colouring as well:

.markdown-here-wrapper pre code, .markdown-here-wrapper pre code span {
  color: black !important;
}

NOTE: .markdown-here-wrapper pre code * does not seem to work. Maybe Outlook doesn't support the * selector?

NOTE: color: initial !important does not seem to work in Outlook. So use black.

This causes a pretty serious problem, though: It removes background, border, and text colouring during composition (even though they'll reappear for the receiver).

I can't come up with a way around this. One thing I tried is to change the rule to use .markdown-here-wrapper:not([data-md-url]). That attribute exists during compose, but is stripped by the mail provider code during send (at least with Gmail web). But...

NOTE: Outlook supports only the most rudimentary CSS selectors. For example, it does not support :not or attribute selectors. (ref)

NOTE: The asterisk style trick for IE7 doesn't seem to work with Outlook (2013).

The only fix I can think of is to only insert the <style> block at the moment that the email gets sent. Which is unfortunate: It will require hooking into the sending, which is only done for Gmail and Thunderbird (with forgot-to-render). And it's a lot more complex than a simple CSS selector.

Well, I guess that's something.

[hansfn]

I had almost forgotten how much I hate HTML e-mails in Outlook ...

I don't care that much but fancy stuff like code blocks, but sending e-mails with lists and knowing that Outlook users will actually see the list is important. Any hope of getting if fix just for lists in a new release of the (Chrome) extension? Any why aren't more people complaining about this? Don't they send mail from Gmail to themselves at work 😉

[ernstki]

@mvhenderson *any version of Outlook on Windows

That's due to the fact that Outlook uses the HTML rendering engine from Word, which lags behind current web standards. There even used to be a web site devoted to getting Microsoft's attention about this problem: fixoutlook.org. Although I haven't tested Outlook 2019, it's unlikely that much has changed, because it apparently still relies on the same HTML renderer.

I think it's important to add that the Mac version of Outlook (from 2011 on) uses WebKit for HTML rendering, and has no such problems with code blocks—or lists, I'm assuming. So if one uses only Outlook for Mac in one's organization—or literally almost any other mail client—then one might still be able to get away with using Markdown Here with those recipients.

The HTML rendering in Outlook:mac is so good that I was actually fooled into thinking "well, if it works in Outlook" for over a year after I started using Markdown Here, until I saw what it actually looks like for my Windows-using coworkers. :(

Here's a good summary of the problems with the Outlook (for Windows) HTML renderer, with workarounds for some specific cases.

[ropolomx]

Hello everyone. I love Markdown Here, and thank you very much for your work! Are there any updates on this? I have no problems when using the Outlook Web App, but unfortunately the standalone program for Windows does have these issues with Markdown. The majority of people I write emails to use Outlook for Windows.

[neilmayhew]

I did find a solution to the code blocks problem. I'm using the forked version of this extension since this original is no longer maintained, but the same solution would probably work with the original if for some reason you can't use the new one.

[lparsons]

Thanks @neilmayhew! I didn't know about that fork until now. It looks like it's only setup for Firefox/Thunderbird. Is there a way to install the fork in a Chrome based browser (so I can use it for Outlook there)? Thanks again.

[neilmayhew]

@lparsons I don't know, I'm afraid. You'd have to ask over there. The driving reason for making the fork was that the original wasn't making the changes required to be able to use it in newer versions of FF & TB and people were stuck, and the maintainer of the fork (who has put in a ton of good work) is a Mozilla employee and (I think) is being paid by Mozilla to work on it. I'm sure he'd be very happy to accept changes to make it compatible with Chrome, but presumably Mozilla isn't going to pay him to do that.

FYI, I'm using Outlook very successfully in Firefox, so I don't think Chrome is a requirement.

[lparsons]

Thanks @neilmayhew, I appreciate the thoughtful and detailed reply. There is already a chrome extension for Markdown Here, which I'm happily using. I'm honestly not sure what it would take to create a Chrome extension, I just figured I'd ask around. I still use Firefox in some cases, but I've gotten myself addicted to some things in Wavebox when I'm "at work" now, and that is based on Chrome.

[neilmayhew]

I hadn't heard of Wavebox before, and it looks pretty cool. I manage the multi-client thing with Firefox containers, and I'm happy with that, but Wavebox does so much more.