Top 5 HTML Email Development Challenges
Email development is a cumbersome task for many web developers, or email developers who are not used to it. They might find it complex to develop HTML emails in tabular format (developing a html email is old school). Due to the different interests, priorities, and policies of the big players in the email industry, there are still no email standards leading to headache for a newbie to understand the multilayered coding style.
Listed below are the challenges that you might face while coding the HTML emails compatible for most of the email clients:
1. Responsive/ Mobile-Friendly
Responsive design is the technique that is used as media queries, fluid images and grids to provide optimal User Interface on various device widths. For example, media queries detect a device’s screen size and subsequently override the styles as specified in it. As noted in the CSS overview, it’s necessary to inline CSS styles, either by hand or automatically before an email is sent. Since media query styles are not default styles, it doesn’t make sense to inline any of it. So, the email’s normal CSS needs to be inlined and the media query CSS needs to override these styles whenever triggered.
Because inline styles have the highest priority in the hierarchy, it’s necessary for every media query style rule you write to be marked with a !important declaration.
The major drawback is that traditional responsive design isn’t supported everywhere. Most notably, Gmail does not fully support styles in the head of an email. So writing css in head is a big no for the Gmail Inbox.
2. Web Fonts Compatibility
As quoted by Campaign Monitor, Web fonts are typically not found on multiple operating systems and devices. They’re specifically designed and licensed for use on websites. Web fonts allow for more creativity for the designer, as they aren’t limited to choosing a font that comes pre-installed on a computer.
Web fonts are not supported by all the email clients. We have a solution for it, i.e., Fallback fonts. Each email client has their own default fonts which the user sees apart instead of the font that was specified.
3. Hybrid Coding
This coding approach, also known as spongy coding came into play when the major email clients like Gmail refused to obey media queries. The idea of fluid tables and images remain the same but these are not achieved by media queries. Hybrid coding takes into account the Microsoft conditional comments. Below are some of the principles on which the hybrid coding rely upon:
- Fluid tables and elements
Unlike the fixed width values for both tables and images, in hybrid coding we use width in percentage. This makes it flexible with respective to all the device widths and the email client viewports. - Max-width CSS for proper width on desktop clients
On the desktop clients, subscribers may see emails of large widths. In order to fix this, we can restrict the widths of tables and images by CSS max-width property. - MSO conditional comments for width in Outlook
In most cases, the above two principles come to the rescue but it is not the case with the very specific and blunt(straight out of coder’s mind) Outlook. To deal with it, we need to use conditional comments to make ghost table that are only visible to Outlook.
<!--[if (gte mso 9)|(IE)]><table align="center" border="0" cellspacing="0" cellpadding="0" width="600"><tr><td align="center" valign="top" width="600"><![endif]--><table border="0" cellpadding="0" cellspacing="0" width="100%" style= "max-width: 600px;"><tr><td align="center" valign="top" style="padding: 40px 0px 40px 0px;"><! --- Content --- ></td></tr></table><!--[if (gte mso 9)|(IE)]></td></tr></table><![endif]-->
Having discussed the major principles of Hybrid design, we can summarize that this approach is a plus when designing a email template as we can combine it with media queries for a enhanced support in other clients as well.
4. Outlook Compatibility
As we know, Word renders emails for Outlook. So there are several common CSS properties that Outlook will not recognize. Some rules are ignored completely while other rules have a different interpretation.
1. Image Distortion
In Outlook, the major issue is of the distorted images. The support for the width attribute for images defined in style tag is obsolete. Outlook only takes width property of html. Below is the fix for the images type (px):
<! — [if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
<o:PixelsPerInch>96</o:PixelsPerInch>
</o:OfficeDocumentSettings>
</xml><![endif]-->2. Head Section CSS Issue
It does not support css written in the head section of the html file. In order to apply css, we need to write them inline.
3. Background Image does not display
Outlook does not render background images, so in order to fix this issue we add the vml code as below:
<! — [if gte mso 9]>
<v:rect xmlns:v=”urn:schemas-microsoft-com:vml” fill=”true” stroke=”false” style=”width: 700px; height: 460px;”>
<v:fill type=”tile” src=”https://mailerstock.com/templates/bureau_v1.0/images/feature-background-01.png" color=”#333333" />
<v:textbox inset=”0,0,0,0">
<![endif] -->Listed above are the major pain points that a developer encounters while making the email templates Outlook compatible.
5. CSS Styles
Though we have come a long way from using old styled email templates to the new, smarter way, but unlike most Web browsers, all the major email clients are not united when it comes to HTML email standards and thus we are bound to use limited CSS properties. A complete breakdown of the CSS support for the most popular email clients is aptly listed in The Ultimate Guide to CSS by Campaign Monitor.
Conclusion
Having discussed the major challenges in development of HTML Email Templates, what we would suggest is that follow the simple and informative approach. Even experimenting with the layouts and using css properties will not hurt much. We have got you covered in both the aspects, i.e., design and compatibility. Do have a look at some of our amazing templates and also let us know if you come across more such challenges.