Coding e-mail templates is a discipline in itself, it is a relatively complex issue and it is doubly true that experience and know-how are the most important.
The encoding of HTML newsletters, signatures and other e-mail templates is not very popular among frontend developers / coders, mainly for one reason – it has nothing to do with the coding of modern web templates.
Basic issues of e-mail templates
The first problem with creating e-mail templates is the huge number of clients in which we can display our e-mail messages. In addition, they are divided into web, desktop and mobile, and to make matters worse, they are usually also dependent on the operating system. So when we think about it, there are hundreds of client combinations for which we should optimize our templates.
What’s worse, however, is the technical obsolescence, especially of desktop, email clients. When coding newsletters, we go back about 15 years, when CSS1 was used and tables dominated all layouts. And tables will be the basic element for us, which we will use for almost everything.
Newsletter Guidelines and Recommendations
There are a lot of hints and hacks that you will come across as you encode and test your email templates. Here are some tips and tricks based on my several years of experience in creating HTML newsletters.
Tables
Tables will become our great helper, we will use them for almost everything. Basic layout with setting the width of our newsletter, displaying content in columns, etc. Only thanks to tables we will ensure the correct display across all clients.
- For all tables, set the attributes cellpadding = “0” cellspacing = “0” border = “0”.
- Use the attributes align and valign .
Fonts
Be sure to avoid your own fonts. Within e-mail templates, we do not have the option of linking custom fonts as we are used to from web templates. Once we can get the font linking there, the mail client will ignore it anyway and display a default instead of our font.
Fonts that we can use safely and are available on most devices can be found in CSS Font Stack . But in general, I recommend using Arial , which won’t spoil anything.
Images
Because most e-mail clients block images by default when they retrieve an e-mail message, they should only be used for non-text elements, where this is not possible. If we have everything over the images (which also happens), including all texts, buttons, etc., the user will see a blank message after viewing the e-mail – the images must first be enabled and downloaded.
- All images should have a display: block, some email clients crop images with a display: inline
- After centering the image, wrap it in a & lt ; center & gt; & lt; img … & gt; & lt; / center & gt;
Decorative elements
If there are any decorative elements in the graphic, typically border-radius, try to resolve them through the images. This is because most clients do not display the border radius.
The same goes for different frames, transitions, transformations, etc.
Indent
Try to avoid all horizontal margins, vertical margins usually only work for paragraphs and lists, sometimes for tables. Set padding on table cells only.
Some clients completely discard margin declarations, sometimes the trick of setting the property to 2x helps, where the second property has a capital letter. The client deletes the first property, but leaves it with a capital letter at the beginning. Sometimes it is also good to add a! Important.
Personally, I try to reset all margins to 0 and I solve the vertical offset of individual elements using so-called spacers . Again, this is a table that has one cell with the height set to the amount of space we want to have.
Line-height
Outlook may have a problem with line height calculation. Line height multiples (eg line-height: 1.5) do not always work properly here, instead it is recommended to use percentages. Ideal settings across clients can be:
Links
I recommend designing all links to be underlined. This is because some email clients add underscores automatically to ensure that the links are displayed uniformly across clients.
If we still need to have links without underlining, try the following:
If we leave the href attribute empty on the link or set it to #, some clients will delete the link.
CTA Buttons
In case we need to encode a CTA button, I recommend reaching for the Buttons.cm tool. This is a code generator that guarantees the correct display of buttons across all email clients.
Background images
In general, I try to avoid background images below the text in email templates, or use the entire image with the text – the only way I can be sure that it’s displayed correctly everywhere.
In some cases, you can use the Backgrounds.cm tool to generate HTML code, thanks to which the background should display correctly across email clients.
More tips and tricks
- Use only CSS1
- Do not use the & lt; div & gt; and & lt; span & gt;
- Write all styles as inline CSS for a given element
- Instead of abbreviated notation of CSS properties, write the individual values separately. Padding location: 0; so type padding: 0 0 0 0;
- Avoid using the CSS property float
- Don’t be afraid to use the ! important declaration in many cases we cannot avoid it
- Hover and focus states are not solved
- Instead of text-transform: uppercase it is often better to write Avoid uppercase text and CSS transformation
- Everything you put between the & lt; head & gt; & lt; / head & gt; tags will most likely be dropped by the mail client
- Do not use Javascript
Test email templates and newsletters
If we release the newsletter to the world, there is no going back and no way to fix any mistakes. Therefore, it is necessary to properly test the templates before the actual delivery.
1. Web browser display
While the email template is being encoded, we’ll likely display it in our web browser on an ongoing basis. If we get it wrong here, it’s almost certain that it will be even worse in e-mail clients. Therefore, you must first ensure 100% display in traditional web browsers.
2. Testing in email clients
We always need to test on the real clients we have available. I recommend having Outlook , Thunderbird , Windows Client Mail , and MAC Client Apple Mail installed on your desktop. On a mobile phone, Outlook , Gmail , Email.com , Apple Mail , and any other default email client on your device. Of those web clients, I recommend testing at least for Gmail , Email.com , and Center.com . This way we can cover a large part of clients used in the Czech Republic.
For test distribution, we can use the free Putsmail tool from Litmus, which is available for free . Just enter the destination email addresses, subject and paste the HTML code with the template. When testing, keep in mind that all images must have an absolute URL and point to a publicly available web server, from where the images will be loaded in the mail client.
3. Testing in email client emulators
As I mentioned in the introduction to the article, one of the main problems is the huge number of clients that need to optimize their email templates to ensure that they display properly. However, it is not in our power to manually test the display on all email clients – on the one hand, we would have to have all the accounts installed in the service for web clients, and the whole thing would take a lot of time that no one will pay us.
That’s why we need to reach for an emulator to make testing easier for us. A popular service I can also recommend is Litmus.com .
Litmus offers email template testing in dozens of desktop, mobile and webmail clients. Just insert our HTML code here, select the clients in which we want to perform testing and Litmus will already generate previews of the images in the selected clients.
Leave a Reply