Summary
When an Office Add-in inserts HTML into a message on Outlook for iOS (for example, an email signature), Outlook for iOS rewrites the inline CSS at the point the content is added to the message body. The rewritten CSS uses modern shorthand and the currentcolor keyword, which classic Outlook on Windows (the Word based rendering engine) does not render correctly. The result is that recipients opening the message in classic Outlook on Windows see missing or incorrect styling, most visibly missing border colors on signature elements.
The same message renders correctly when opened in Outlook on the web, new Outlook for Windows, Outlook for iOS, and Outlook for Android. Only classic Outlook on Windows is affected, because only the Word rendering engine fails to interpret the rewritten CSS.
Who this affects
Any organisation using a third party signature Add-in (or any Add-in that injects styled HTML) on Outlook for iOS, whose recipients include users of classic Outlook on Windows. This is a large population: classic Outlook on Windows is still the default client in many enterprises.
We are raising this on behalf of a significant number of affected customers who currently have no workaround.
What we observed
We insert this HTML into the message via the Add-in:
<td align="left" style="padding:12px; border-top:none; border-right:none; border-bottom:none; border-left:solid 8px #F5F736; vertical-align:top; font-family:Calibri,Arial,sans-serif;">Outlook for iOS rewrites it, before it is committed to the message body, to:
<td dir="ltr" align="left" style="white-space: nowrap; border-width: medium medium medium 8px; border-style: none none none solid; border-color: currentcolor currentcolor currentcolor #F5F736; padding: 12px; vertical-align: top;">Two behaviours are problematic:
- The individual border-top, border-right, border-bottom, border-left declarations are merged into border-width, border-style, and border-color shorthand.
- The merged border-color uses the currentcolor keyword for the three unset sides.
Classic Outlook on Windows does not honor currentcolor reliably in this context, and its handling of this particular shorthand combination drops or miscalculates the actual colored side. The colored border the sender intended is not displayed to the recipient.
Why this is a problem specifically for Add-ins
Authors of Office Add-ins cannot control what the host client does to HTML after body.setSignatureAsync, body.setAsync, or equivalent insertion APIs are called. The HTML we provide is valid, and it renders correctly on every other Outlook surface. The rewrite is happening inside Outlook for iOS, silently, and we have no API to opt out of it.
Reproduction
- Build a simple Outlook Add-in that inserts the HTML snippet above into a new mail message using the standard Office JS body insertion APIs.
- Send the message from Outlook for iOS (tested on iOS 18.3.2, Outlook for iOS 4.2513.1).
- Open the sent item in Outlook on the web or Outlook for iOS: the yellow left border renders correctly.
- Open the sent item in classic Outlook on Windows: the left border color is missing.
Prior report
This was previously reported against Office JS on GitHub: https://github.com/OfficeDev/office-js/issues/6521. The response was that the issue will not be fixed in the short term, and the recommendation was to raise a Tech Community item so the team can gauge demand. That is what this post is for.
What we are asking for
Ideally one of the following:
- Stop Outlook for iOS rewriting inline CSS that was supplied by an Add-in through the supported insertion APIs. Pass the author's HTML through unchanged, or
- If normalisation has to happen, avoid emitting currentcolor and avoid collapsing per side border properties into shorthand in ways that known Outlook rendering engines cannot interpret, or
- Publish a documented, supported HTML and CSS subset that is guaranteed to round trip across all Outlook clients (including the Word rendering engine in classic Outlook on Windows), so Add-in authors can target it deliberately.