For most of us, producing a professional email at work is easy - open your chosen mail client; select your recipients; add a subject line and type your content. If you're anything like me the hardest part is tweaking the wording so that it puts your message across with the right professional ambience.
This process suits most of us during our day-to-day lives. Most email applications allow us to go further than basic text, quite often providing full text editor functionality, this is more than enough functionality for the scenarios which most of us are ever likely to encounter.
But there's a step beyond that which we don't usually have to think about, fully formatted HTML emails like those from Amazon, eBay and countless other services giving us account updates or sending marketing communications.
Going about producing an email with this level of professionalism is a whole step above what most email applications are capable of.
We might assume that all we need to write an HTML email is some basic HTML knowledge. To a certain extent this is true; but - unlike modern web browsers which receive tend to have high-pace release schedules and automatic updates - email clients tend to remain static.
Put simply, email clients are stuck in the past, if we want to write a professional looking HTML email, we need to take that onboard from the get-go.
Email Clients
Email clients come in three distinct categories - traditional windows applications (such as Outlook or Apple Mail), web based applications (such as Gmail or Outlook.com) and mobile applications (like Apple iPhone or Samsung Mail).
In 2019, Litmus reported that usage of web based email clients and mobile applications were evenly matched with mobile apps remaining marginally ahead of web clients for the past three years. Usage of windows clients has remained at around 18% for the last four years but interestingly the data shows a potential upward trend.
The other important piece of information that this report shows us, is that Microsoft Outlook is the third most used email client; this is up from #5 the previous year and accounted for 9.2% of all recorded email opens.
The reason that this is of particular importance is because Outlook uses Microsoft Word to render emails* and has done since 2007. As a consequence, Outlook suffers from a bunch of behavioural quirks which adds an extremely high level of complexity to HTML emails. Microsoft have previously indicated that they may be willing to address this, however as of Outlook 2019, little has changed; and even if they had swapped to a web based rendering engine we'll still be picking up the pieces from older installed versions for years to come.
I'm still running Outlook 2013 on my personal laptop (although I now rarely use it), my office PC runs Outlook 2016 which gets used all the time. However I can't see myself going through the hassle of upgrading it any time soon.
* Except Office 2011 on Mac which used a separately bundled email application.
Email Content
Conventional web development practices advise positioning elements using divs and floats. More recent practices expand on that with advanced CSS functionality such as Grid and Flexbox.
None of this more advanced functionality can be applied to emails because Outlook cannot possibly support them. We're also restricted because of the nature of displaying an email within a browser:
- Use of CSS is mostly restricted to inline styles (because we don't want styles from the opened mailing breaking the layout of the parent page).
- Use of JavaScript (imagine the security implications).
- Use of iFrames - (Limited use in some clients*, unlikely to be of wide use because of the implications of introducing CSS style tags and JavaScript).
- Embedded audio or video content is unsupported by most email clients (I get annoyed at social media videos that auto-play, doing so within an email would be a sure-fire way of a sender getting themselves blocked).
- Forms - a number of email clients treat forms as a security risk, some will trigger spam filters.
- SVG Images are largely unsupported by the majority of email clients.
* As noted by Campaign Monitor
With all these restrictions in mind and to support the lowest common denominator; we have to go back in time and properly format our content using nested tables. We'll also need to be more cautions about our choice of formatting options, resisting the temptation to use more recent CSS options and where possible defer to HTML attribute equivalents such as align, valign, cellpadding, cellspacing, width, border etc.
Email CSS Styling
In the past, support for CSS styling within email clients has been quite patchy. Although this has been gradually improving, we're still greatly restricted by the email clients that our recipients will have installed.
A large percentage of web based clients now support <style> tags (best placed within the <head> section) while a small percentage support externally referenced CSS files using <link> tags.
As a best practice, all CSS styles should be applied directly to elements using inlined styles. In practice it's useful to create CSS styles in the usual way and use a third party tool such as premailer to automatically inline our styles and reduce bugs. Style tags should be used with caution, tho they still have their place when it comes to responsive email design.
Unsurprisingly, support for CSS styles within emails isn't as wide ranging as it is in normal web development, we have a core group of CSS options available to us, after which we'll need to take an approach of progressive enhancement when adding other functionality.
Safe CSS Properties
CSS properties which are well supported across all email clients or that can be used without fear of causing display issues in other clients.
Well Supported CSS Properties
CSS properties which are supported by the majority of email clients, can be used with the appropriate fallback or using a pattern of progressive enhancement.
CSS Properties to Avoid
Font Styling
As with fonts on websites, your selected font depends on the fonts available on the users system; it's always best to select a fallback when working with a less common font. The same goes for web-fonts, which not all email clients support, again requiring that a suitable fall-back is in place using inline CSS.
We also need to be conscious that CSS support for font styling options under older email clients can be a little erratic. To be absolutely certain of applying bold, underline, italic and strike-through styles we need to fallback to <strong>, <u>, <em> and <del> syntax.
See this article by Mailchimp which digs deeper into font usage in HTML email.
Responsive Email Design
Responsive design is best conducted when creating emails with a predefined maximum width in the region of 600-800 pixels, this range covers the width available in the majority of applications. There's little point in expending time on sizes not generally required by users particularly with the reduced levels of content in email communications.
The 600px figure goes back to the days of 1024px x 768px screens and the size of Microsoft Outlooks viewable area in those days with around 424px taken up by outlooks sidebar and the vertical scroll for email content.
With responsive design we have a bit more flexibility, but we still have to consider other non-technical elements such as the users attention span over longer lines and how much harder it is to trace back to the beginning of the next line without losing your place.
Many email clients still require their content to be held in a base table, so as far as responsive design is concerned, this has to be our starting point.
We'll configure a parent table with 100% width, this would perhaps contain a default background colour which differentiates itself from the mail client. We'll then add a child table, this table is assigned a max-width within the desired range and forced to the centre of the viewable area.
Note that wherever possible we're positioning our components using older style attributes rather than CSS styles.
Our responsive options when building HTML emails are greatly restricted without the likes of Flexbox or CSS Grid to work with. We do have the ability to write basic @media queries but should we use them?
Writing a responsive email isn't like putting together a responsive website where you have maybe three or four major browsers to worry about, most of which are based on Chromium anyway.
Device types, widths, pixel density etc are far more varied, just because we can use media queries doesn't mean that we should use them for anything more than progressive enhancement.
Our alternative to media queries is to use an approach termed as "fluid-hybrid". With this process we don't need to worry about matching screen designs to different sizes. We create a parent "ghost" table which has a width value of 100% and a max-width of our maximum defined email width defined in pixels (say 600px), into that table we add our "responsive" elements in the form of additional table elements or containers each with the same 100% width value and an appropriate max width (say 2 equal columns each with a max-width value of 350px).
Taking this approach means that our email content will always fill the available space and will naturally drop from columns to rows when the screen width is not wide enough.
Other Areas of Concern
Regardless of which approach we take, there are a number of areas that we may need to give consideration to:
- When supplementing inline styles by using CSS style tags, be sure to make use of the `!important` flag where there may be overriding properties within the inlined CSS, as this will take priority.
- Split any responsive CSS code into separate style tags, if there are any errors or compatibility issues then the client may strip the entire style section from the email source, separating CSS into sections will reduce the likelihood of this causing further problems.
- When configuring media queries on mobile devices it's easy to concentrate on device width as we would do normal responsive web development, but pixel density varies more widely on mobile devices. This should also be considered when selecting images to ensure that users have nice crisp and clear experiences regardless of device
- When using GIFS, remember that some mail clients will only display the first frame.
The Future: Dark Mode
With the increasing use of dark mode options within email clients (with Gmail recently introducing this as an option), dark mode in email design is becoming more prevalent.
Email clients are still figuring out the best way of implementing dark mode, some just change the email interface while others provide varying degrees of colour inversion.
The core problem around dark mode is display of images and HTML elements traditionally designed to work on a lighter background. For example a darker logo on a transparent background won't be readable in dark mode. Most of these sort of issues can be tackled with a little forethought but this is really just scratching the surface of what will be possible in the future.
For reference, Litmus have produced a guide on how to tackle dark mode in emails here.
Final Thoughts
Know your audience: With the inclusion of an invisible 1x1 pixel image we can read the client user agent string and retrieve some basic information without breaching GDPR, CASL or any other data protection regulations.
This can be decoded to give us information about the type of device our recipients are using and the application they're opening it with.
While there are some scenarios where an email client may not automatically render images, this approach should give us enough information to identify the range of devices our emails are being opened with. We can then adjust our approach accordingly.
Test, test and test some more: If budget allows, use an email testing service, such as Litmus or Email on Acid which will automatically test your email content to give you an idea of how it would appear under different devices.
Don't forget about plain text content: We can produce fancy looking emails, but we can't forget that even now, not all email clients can read HTML content. Perhaps users have HTML content turned off for accessibility purposes, perhaps they're still using an old blackberry, perhaps they're reading an email on an iWatch. Even if it's automatically converted from HTML. Plain text email conent may not be as important as it once was, but it's still important.
Don't over complicate: The idea of keeping to a simplistic design doesn't just apply to HTML email content. The range of devices and applications available makes it a far greater concern than normal.
In the end, there's no point in producing a fancy email design which will only work for 20% of users. When in doubt, keep designs simplistic to reduce the likelihood of display issues in different clients.
Content is still king. For all we can achieve with HTML email, if the end result is that if we force users to think about how they're going to read an email then it's not worth it.
Top comments (0)