Challenges of HTML mail coding: Coping with the characteristics and limitations of different mail clients

The most difficult problem with HTML mail encoding is that each mail client has its unique features and limitations. These differences usually stem from features added by clients in good faith, such as automatically converting plain text website addresses into clickable links, but bringing complexity to email development. In addition, security issues are also crucial. The email client needs to ensure that the HTML and CSS of the email do not interfere with the HTML and CSS of its own interface. Malicious emails may use certain CSS attributes (such as absolute positioning) to induce users to click on hidden links. Therefore, the mail client should parse, filter and manipulate HTML mail codes, but this means that we as mail developers must be aware of this and make our code as friendly to them as possible. This article is excerpted from "Crafting HTML Email" on SitePoint Premium, which summarizes some important tips and tricks in HTML email development.

Key Points

Client-specific differences:
• Because each mail client has its unique features and limitations, HTML mail encoding is extremely challenging. These differences often stem from features such as automatically converting text into clickable links, but complicating the email development process.
Outlook's unique rendering engine:
• A considerable portion of the email market share is occupied by Outlook, which uses Word as the HTML and CSS rendering engine. This requires specific encoding methods to ensure that messages are displayed correctly in Outlook, including understanding the limitations and features of Word rendering.
Adapt security measures and style restrictions:
• Mail clients implement various security measures to prevent HTML and CSS from interfering with their interface, which may cause some CSS properties to be modified or filtered. This requires a cautious and informed approach to HTML mail coding and styling to ensure compatibility across different clients.

Support Outlook

In January 2022, Outlook (Windows and macOS versions) accounted for 4.44% of the email client market share, according to data from the email analysis tool Litmus. This may not seem like much, and remember to be careful with email analysis data, but there is a good chance you will encounter Windows versions of Outlook during email development.

Here is what you need to know to make your HTML mail run seamlessly in Windows version of Outlook.

How does Outlook rendering engine work

Since 2007, Windows versions of Outlook have used Word as the rendering engine for HTML and CSS. Microsoft explained why Word was used in 2009:

We decided to continue using Word to create emails because we believe it is the best email creation experience, with a wealth of tools Word users have enjoyed for over 25 years.

Word is not only not good at rendering HTML and CSS, but also has extremely lack of documentation in this area. The only existing official document on Word rendering is a blog post published by Microsoft in 2006 that explains the rendering capabilities of HTML and CSS in Outlook 2007.

This includes the following information:

• CORE: Color, background color, text attributes (font, font series, font style, font size, font thickness, text modification, text alignment, vertical alignment, letter spacing, line height, blank) , border abbreviation properties (border, border color, border style, border width, border collapse) and some other properties.
• COREEXTENDED: Text indentation and margin properties (margin, left margin, right margin, upper margin, lower margin).
• FULL: Width, height, fill (as well as left fill, right fill, upper fill, lower fill) and border complete properties (left border, left border color, left border width, left border style, etc).

and each category only applies to certain HTML elements:

1. <span></span> and <font></font> only support CORE attributes.
2. <div> and <code><code><p></p> support CORE and COREEXTENDED properties.
3. All other elements supported by Outlook (such as <table>, <code><td>, <code><tr>, <code><th>, <code><tbody>, <code><tfoot>, <code><thead>, , , <p>, etc.) support the CORE, COREEXTENDED and FULL properties. <code><table> <code><table> <code><td> This means we have to consider which element to use to apply a specific style. So if we have to define the width or height on the general container element, we will use . If we need to fill, we also use <p> and <strong>. To this day, Windows versions of Outlook are still the only reason we still use forms in HTML emails. Fortunately, there are ways to make these tables visible to Outlook only, hide them from more powerful mail clients, and allow us to use more semantic code. </strong> </p> (The following content is limited by space, only some overview of key technical points will be retained. Please refer to the original text for the complete content) <ul> <li> <strong>Conditional comments:</strong> Use conditional comments to add specific code to Outlook. </li> <li> <strong>mso-Properties:</strong> Use Outlook's proprietary CSS attributes (prefixed with <code>mso-) to implement specific styles.
4. VML: Use VML (vector markup language) to simulate properties that Outlook does not support, such as background images.
5. 120dpi rendering: Solves the display problem caused by Outlook applying DPI scaling in some Windows configurations.
6. Avoid automatic linking: Use various methods to avoid the email client automatically converting URLs, email addresses, etc. into links.
7. Use real URL: Avoid using non-url text in the <a></a> attribute of the href element.
8. Add empty: Solves the issue of removing elements on Yahoo Mail on Android.
9. Keep email size below 102KB: Avoid Gmail truncating email content because the email size exceeds 102KB.
10. Remove CSS comments: Avoid style failure problems caused by Yahoo and AOL clients due to CSS comments.
11. Use HTML5 document type: Handle the effect of HTML5 document type on the line spacing of <img alt="Essential Tips and Tricks for Coding HTML Emails" > elements.

Conclusion

The feature of processing mail clients is part of the work of mail developers. It is important to follow the email developer community and be aware of the latest updates and practices. By reporting on issues we observed, the mail client can improve and fix its own code. While this is a slow process, I do feel that HTML mail is heading towards a better future with better interoperability and standard support. This will open the door to more fun and exciting features such as interactiveness!

Please note that due to the length of the original text, this output simplifies and summarizes some technical details. For more detailed information, please refer to the original text.