JKDesktop Outlook HTML/CSS Support Wishlist
Hey guys, got a ping from the Outlook Team. They are looking to address our qualms with Outlook rendering and would like to start with two requests - examples of bad outlook rendering and high priority HTML/CSS support.
This will only be about the Desktop and Universal Outlook versions and not Outlook.com/365 or the current Windows Mobile Outook client.
I would like to dedicate this thread to high priority and nice to have HTML tags and quirks. See this other thread for posting examples of broken emails in Outlook.
When posting list them under these headings (in order of priority):
High Priority Outlook HTML/CSS support
(ie. div/block element width/height/display/overflow support, CSS background-image support, table background)
Perhaps a good place to start: http://www.email-standards.org/clients/microsoft-outlook-2007High Priority Exchange ActiveSync (EAS) HTML/CSS support
(ie. ???)Nice to have
(ie. pseudoclass support, forms, absolute positioning, WebFonts, media queries (for Universal Outlook)).Common Outlook slip-ups
Outlook specific quirks that often cause problems in your designs
I'm also aware of some previous efforts in this area and will incorporate them into my response:
http://www.email-standards.org/acid/
https://blog.jmwhite.co.uk/2014/08/19/email-campaigns-windows-phone-part-3-exchange-activesync/
By the way, I KNOW the answer is "Just render emails in a browser like Outlook 2003 or Outlook for Mac" but just trying to establish some goodwill here :)
I saw someone allude to this once on twitter - I can't recall who it was so credit to that person if I can find them.
Also, I don't think they'd ever do this but here is what I'd like to see:
First thing to consider is why does MS use Word as a rendering engine? The primary reason I can see is to create a rich experience for their users. You can open Outlook, hit New Message, drag a Power Point presentation and an Excel doc in and hit send. When your coworker opens this message in their Outlook they can dive right into these docs in the message. It's a compelling use case and people are doing this at their jobs all day long.
Similar to how you could tell IE which versions you designed against with Compatibility Mode, we should be able to include a meta tag for render mode.
<meta http-equiv="X-Render-Mode" content="html" />If this tag is present I know I am sending an HTML email. I am asking Outlook to use a browser control to render this message. I am consciously opting out of the MS Office ecosystem. Sure my messages will lose some functionality - I can't embed an Excel doc in them. I think providing a list of tags / css to support is silly. I want you to support all of them.
The technical challenge in this approach is how to handle when the user hits fwd or reply. Do you convert the message to a Word doc at that point? But surely they could tackle that challenge as opposed to the challenge of getting a Word control to support all the various HTML and CSS that people want to see.
The irony is that the meta tag in email idea was Microsoft's! They used this to enable CSS3 support on the Windows Phone 8 email client.
I totally agree there's no reason not to use the browser control to render email (especially since the Office API allows embedding browser controls in Outlook!) In fact I believe Outlook for Mac uses Word to author and Webkit to render.
As for fwd or reply, the message has to be converted to doc at some point why not delay it until the fwd/reply instead of during the view?
Providing tags/css might be a pointless exercise, but the hope is when they see the totality of tags/css needed, they just might come to the realization themselves.
Irony is rife in Redmon. I always get a chuckle when I go to look some element of VML up and I'm greeted with a disclaimer that it's been deprecated.
I've had some time to think about this and I think this would be the holy grail fix that could easily solve most of our issues. I was going to try to provide two top options but this is something that should be less complex to implement – especially since it's already partially baked in. This is also something that should be able to be applied to older versions easier and could even be included in a security update to help ensure it gets applied.
The forward, reply issue is a little more difficult, but what would be ideal is to create a a new mime boundary for the html portion of the email and have the primary mime section for the portion composed in word by the user. The only reason to convert an HTML email into a doc would be to edit the email and I would suggest that would just be another feature that would be lost if you chose to set the meta tag on the original email.
I think this solution is elegant and would solve 90+% of the issues we have to deal with and would potentially have less hurdles to overcome to be implemented by the Office team.
AMAZING!
Great work Justin :D
I'm going to try and be as conservative as I can with my suggestions, even though all I want to ask for is full CSS4 support #CanHas:Has()
Absolute basics
Nice to haves
Things that affect the user
(x)( )( )( )and[x]If they don't support them then showing nothing would be a huge improvement.Also it's worth noting that the best thing currently about Outlook is conditional comments. It makes it much easier to work around the bug and also deliver specifically target content to the user. If they no longer support these in the future then something like Outlook.com ExternalClass would be great. Whatever they do, there will always be bugs so a way to specifically target these would lead to a better experience all round.
Hope that helps mate,
Cheers,
Mark
Oh yeah and <li> support would be nice.
Great list, Mark! Thank you.
-Julia Foran, Microsoft Outlook PM
What Mark said ☝
Could they use the same rendering engine as Outlook 2016 for mac. And how does Outlook 2016 works with the other office programs on mac?
You should remove the floating from you list. Floting isn't supported on Android devices from version 4.3.2 to 4.4.4, and that is almost 45% of Android market share.
Do you have evidence of that?
I have several litmus test showing Android 4.0 rendering floats correctly.
Yes. Try to float
<td>and test in Native App on Samsung device with version between 4.3.2 and 4.4.4.interesting! so to their point about examples of Outlook rendering causing challenges for users. Aside from the obvious things, lack of support for bits and pieces etc, the larger challenge is that the specific way we need to code in order to support Outlook causes a long chain of events that impacts the email experience across the board. There's a few other places where divs have challenges, for example, but on the most part, we use tables for layout because of Outlook. This entire approach immediately restricts our work on mobile, or at least makes it more difficult, and means we move away from a semantic, hierarchy based approach, which in turn has a massive effect on accessibility in email across all clients. The way we have to deal with Outlook rendering not only affects Outlook users, but the entire email ecosystem.
The challenge of course here is that even if Outlook were fixed tomorrow, there's till hundereds of thousands of installs out there of legacy software. Indeed I recently had lunch with a sysadmin at a major financial org, and when discussing this, he told me that they actively go for one or two versions back. In fact that morning he'd been installing Outlook 07 for some users. They're institutionally reluctant to go with the latest version of anything – they see older version = had more bug fixes (I know...)
This. This should be the core of the response: “…Outlook rendering not only affects Outlook users, but the entire email ecosystem.”
As for those cases of “…institutionally reluctant to go with the latest version of anything”, we still have progressive enhancement until this ridiculous proprietary gap is closed.
I agree that this is the biggest issue, especially as Outlook support is really an enterprise issue.
Obviously changes going forward are great, but even if those are made it won't change things for us much for many years to come. To take a page from the web world, look how long b2b sites had to support ie6 and 7 after newer, better versions of IE were released. If there was some inkling that they were considering patching previous versions I might get a little more excited; I doubt something of that magnitude is something they want to budget resources for.
If there was one issue that they were to devote resources to fix in older versions it would be forwarding. While better div support would be awesome I have a feeling that would be timelier resource drain than changing how forwarded html emails are handled. Even with all we can do with VML and other inventive hacks, Outlook largely chokes when someone hits the forward/reply button. Even if they made it so that an html email was forwarded as an attachment of the original email – code unaltered – it would go a long way to making my life less stressful.
Yeah its sad we had to wait 8 years to get here and probably more before this gets resolved. I think depending on which path they take, the issue of legacy clients might be easier or harder to fix.
IF they merely switch to the browser control, I believe the fix would be relatively straightforward (since you can "view in browser" anyways in Outlook 2007/2010/2013) and they could just release a patch for the old clients that sysadmins can decide to install or not (the sysadmins might if we decide to move from tables and their users start complaining that their emails are starting to look like cr*p).
However if they make changes to the Word engine to address this, then the older clients won't get the fix and winter will be with us for a long time to come.
This is great news, thanks for leading the charge for us!
I think a few basics that control email layout could go a long way. Things like:
<style>and media queriesBasically everything in your first bullet. A lot of the other stuff could be extra credit... things we can progressively enhance to.
This is the dream... switching the rendering engine to Trident or EdgeHTML would solve most if not all of our issues. Given how entrenched Outlook is in Office business unit at MS I doubt switching the rendering engine from Word is on the table though.
I feel like a lot of issues we face with Outlook could be sorted by moving away from the Word/Office rendering engine. It's that that forces us to use hacks to ensure we've got the right spacing and even having to use tables.
"Could you share some research you have demonstrating the impact to users, particularly ones reported by users themselves? "
Most users don't complain, they switch.
2011 - Outlook was 37% of total opens in Litmus
2015 - Outlook was 8% of total opens in Litmus
Now you could argue that there are other reasons for that drop, but it's tough to argue that poor support for HTML email isn't one of them.
From my experience as a developer, nobody in my office or building for that matter cares about the level of HTML support in Outlook! It's only developers that ever notice these things. The drop has to do with the advent of mobile devices... look at any website's traffic in 2011 compared with 2015, you will see the same huge changes, nowadays most traffic comes from mobile devices (phone/tablets) while in 2011 mobile traffic was insignificant.
But definitely there is no user that ever thinks hey, Outlook html support is not very good :)
They may not label it as such, but switching email clients occurs for a number of reasons. It is not as simple as the “device at hand” premise. Many people switch – including multiple opens of the same email – specifically because of rendering issues.
Example case: This email looks horrible here.
Solution 1 - delete. ~80%
Solution 2 - open on another device. ~15%
Solution 3 - do nothing and read on. ~5%
I agree with you on that, but I think Solution 1 is much higher than 80%. Most consumers won't take time to load an email on another device or via the web unless it's an email from a brand they are truly invested in.
I'm with you, Silviu! And what they do notice is how similar Outlook is to Word and Excel, apps they spend all day in. And it integrates well with calendars and reminders... Outlook is pretty well entrenched with they average worker around here. Few non-designer folks notice sub-optimal design elements.
Good point! However on Windows, what's the alternative?
Gmail in browser and apple products most likely.
I think a heavy dose of historical Litmus data + email rendering errors in outlook vs same email in other clients would be a powerful setup to the suggestions for html/css support.
High Priority: Stop/Fix DPI Scaling!
Or just get it right.
While I agree with the others regarding full support for
<div>s, CSS, etc. what really drives me nuts now is the weird Outlook DPI scaling on HD touch screen devices. It's not a large user group, But I've had clients where a stakeholder as a new fancy touch screen laptop and the image sizes are weird and the email looks broken. Things likeborder-radiussupport are nice-to-have, but the email isn't broken.For more details, see this Litmus Thread
I understand why you might find the DPI scaling necessary. But I think you are worsening the user experience, rather than improving it. A broken image is worse than a blurry image. Perhaps Microsoft should just trust us email developers to do our job and serve proper code and image sizes.
totally agree stop the DPI crap!
This could be promising, but I won't hold my breath.
High Priority Outlook HTML/CSS support
@font-face
background (images, position, repeat, size)
margin/padding fixes
line-height fixes
float fixes
Nice to have:
border radius
max/min/default width/height
canvas, audio, video
selectors (:hover, :before, and :after especially)
My list would basically be the same as Matt's. I would definitely love to see support for background images. Any way we could eliminate the majority of the hacks we currently have to do.
High priority:
Div (positioning and width)
max-width
height:auto; (for images)
Nice to have:
margin:0 auto (for positioning divs)
correct line-height measurement
@font-face
support for animated gifs
float (and clear)
better support for alt text
Thank you so much Justin for organizing this, and thanks to Microsoft for finally reaching out and listening to email developers. I think most people here have already pointed out the most important stuff. But I just want to emphasize my priority.
My biggest wish for the next Outlook is to have a basic CSS box model support. I want to be able to use
display,width,min-width,max-width,height,min-height,max-height,padding,margin,borderreliably, on any HTML elements. The current Word rendering engine only some of these properties on some tags, and this is not good. Once we have that, we'll be on par (as far as layout is concerned) with other webmails like Gmail or Outlook.com. And we'll no longer have to use tables for layout ever again, and email development will finally have a foot in the 21st century.this. A lot of pain has been caused because these simple properties aren't supported.
HTML/CSS Support:
Exchange ActiveSync
Unifying the HTML/CSS support level with generic email protocols and EAS (Exchange ActiveSync) would be a good thing as well. Often you can find completely different email experience on the same device/client simply because of using an Exchange email account. There is very little information about EAS and its rendering engine details, but my article (linked by Justin) shows what happens.
Windows 10
I am however disappointed the Outlook team are not reaching out about the Universal Outlook client in Windows 10, as that's the future of Outlook. While it is still under development, the early first looks at it, show an absolute train wreck of an experience for email development. In my opinion, the Word engine should stay well away from the mobile space in an email client, simply because of all of the issues Outlook on the desktop has, but that's Microsoft, fingers in ears.
Cautiously optimistic about this.
Hi James - thanks for the feedback. We do plan to address content rendering in both Desktop & Universal.
-Julia Foran, Microsoft Outlook PM
Hi Julia,
This is certainly great news. I misread the original post from Justin! My apologies.
I'd be certainly interested in seeing improvements to how Outlook Mail is on Windows 10. I've been pretty vocal on this after seeing the first previews of it in the desktop and phone builds (10051 and 10080). I think this alone demonstrates how the current Outlook rendering engine really isn't suitable to the mobile space, without a modern modern web standards approach.
Thanks,
James
Hi James,
We are looking into improvements that can be made to Word for better rendering in Universal Outlook. We know that this is going to be painful at first - moving from a browser rendering in 8 to Word rendering in 10 - so examples of mails that are unreadable or lose message due to poor rendering would be very much appreciated to help us plan out these improvements.
Regarding EAS, I had forgotten about this post until after I replied to another blog post from you (https://blog.jmwhite.co.uk/2014/08/19/email-campaigns-windows-phone-part-3-exchange-activesync). We can discuss there if you prefer?
--Julia Foran, Microsoft Outlook PM
Hello Julia,
It is certainly refreshing to hear that Microsoft is listening and wants to change things, based on the feedback provided in this thread.
I think the community at large has the examples of broken emails covered in the other thread Justin has mentioned in the original post. Without repeating too much of what's been written by others, I'd say from a generic technical perspective the following points attribute to broken emails in various forms within Outlook and the Word Engine:
Those in my opinion are the fundamental areas that create the disparity between other email clients.
In regards to EAS. I read your comment on my blog post, thank you taking the time to post there. If what you've said is correct, EAS is very strict, because its HTML/CSS support is even lower than Word in some cases, that's got to be a problem right there. Security was cited as one of the reasons for this behaviour, that is understandable to a point, but if its the sole reason why the experience is degraded, an assessment has to be made on if the pre-processor is actually doing damage rather than good.
I am open to however you want to engage with it further, you can also contact me personally if you wish or if you'd like to continue the conversation here for transparency, that's fine with me also!
First, thank you so much for this. This is excellent and encouraging news. Microsoft has done an excellent job listening to the community while developing Edge. Let’s hope that continues.
Next, as part of your response – in addition to aggregating the community requests – please please please invite Microsoft to join the W3C HTML for Email Community Group. The solutions we seek should be documented standards.
Hi Charles, Thanks for letting me know about that group. I signed up to join it.
--Julia Foran, Microsoft Outlook PM
Need to get back on this. I'd planned to go through the entire HTML 4 and CCS 2 and assign priority.
How about just switch all outlook clients to using Webkit. Please oh please.
Margin, Padding, Float, Box-Shadow, Divs instead of Tables.