The state of HTML and CSS support in email clients: Limitations & Workarounds

Writing markup html for a) either an email signature b) or for a template of an email newsletter can be quite challenging. This is due to limitations of email clients. They lack support of quite some modern CSS properties, HTML features, linking to external resources and positioning and layout techniques.

Goal of this article is to demonstrate how to overcome some of the aforementioned challenges with standard html and css alternatives. Additionally we will show which of them to surely avoid in order to ensure your email markup will always be properly rendered in any email client. Before listing the technical constraints and the proposed alternatives for some of them, we will first show the process of writing and testing markup code for our email signature.

By default Gmail’s signature compose text area is quite basic and allows only text and some basic formatting. Thus many email signatures are quite basic containing some logo image and some hyper-linked texts. For more custom email templates with a professional look someone needs to write markup code instead of plain text. But how exactly can we place the markup code we created locally in visual studio into gmail’s signature editor? For that we need to install the Chrome Extension Insert HTML by Designmodo. This Extension injects an icon inside Gmail’s Compose text area and when clicked allows the insertion of custom html format.

Beware that during creation of markup and before it is finally rendered in our email it is sequentially tested in the following 3 different views-browsers:

Localhost View in Standard Web Browser: Firstly we locally test it in our standard web browser after we have coded it in an IDE such as Visual Studio. Whatever we see rendered in this View will not necessarily be reflected in our final email signature, as the standard web browser is more developed and supportive of modern css and html features comparable to email ones. However it’s a good starting point to test our layout.
Preview Mode in Gmail’s Compose Text Area: Once we finalise the markup in the previous step we copy and paste it in the injected view of the designmodo icon mentioned above. Once we click save on the injected markup view, we see email signature’s email design in the preview mode of gmail’s signature editor. This preview is shown inside Gmail’s Compose text area and it is not always identical to our email’s signature client. That’s why we need to pay attention to all the differences between the visual elements that are shown fine in this view and not on the next one. First we need to click once more save, in order our new signature to be updated.
Final View in Email Client: During the creation of a new email we can see eventually our email signature at the bottom of the body text. That’s the final view we care about. This is what our email receivers and customers will see. At this stage, it would be nice if we test the email signature in quite a few email clients for example gmail, apple’s default mail client, thunderbird etc

The approach we are presenting in this post is code-based and provides more control to the engineer to built advanced templates tailored to their branded designs. However, there are other techniques we could follow in order to build custom email signatures, of smaller visually complexity comparable to the ones we are aiming at this post but more advanced compared to the very basic ones we can built with gmail’s default built-in text-based only editor. These can vary from:

Copying Word Documents Tables: We can use tables in word documents where we structure the layout of email signatures. We place all content in the cells, both plain text, images and hyperlinks. Once we make the border obsolete we can copy the table as whole onto gmail’s email compose editor.
Right-clicking on Rendered Html Content: In this approach we copy the generated html that is rendered in the standard browser into the compose text area of gmail. This is be done by first selecting in the browser the visual content and then by right clicking on it we select “copy or copy as html”. Then we paste it onto gmail’s compose editor.
Using External Software: using external tools such as Wisestamp or MySignature to generate the html for you. You only need to visually select your elements and no need to worry about which css and html feature is supported by the email clients. Limitation is the you cannot create a fully customizable template.

After having defined the workflow of building an email template with custom markup let’s now elaborate on the constraints of email clients.

The following features are not supported and should be avoided:

Complex CSS Selectors such as sibling selectors ~ and child selectors > are not supported.
CSS Pseudo-classes like :hover, :active, :focus are not supported
Advanced CSS such as animations, transitions not supported
Interactive HTML elements such as forms and javascript are not supported
Background Image properties are not supported: Background-size property does not work
Content Security policies: Some email clients strip out certain HML tags such as <iframe>, <embed>, <object>, <script>

The following features are not supported but there are workarounds and alternative solutions:

Advanced Layout techniques such as Flexbox, CSS Grid are not supported: Use Tables instead.
Position: relative/absolute/fixed are not supported: Use a combination of tables, paddings and line heights instead. Other alternatives are spacer images or text-align property. Depending on your design problem you use one or a combination of these.
Custom fonts like Google fonts are not supported. Stick to web safe fonts such as Arial, Times New Roman, Verdana.
Inconsistent support of Media-queries: Design responsive layouts that degrade gracefully into vertical layouts. Use for example relative units such as rem or em for your fonts and your widths. Don’t exceed the width of your signature to more than 37rem.
External stylesheets are not widely supported by email clients. The usage of inline styles is recommended.
Inconsistent support of margins and paddings. Use nested tables, cellpadding and cellspacing instead.
No embedded Images. Use self-hosted ones with absolute URL’s.
No embedded Videos. Use a static png with a referenced play button to a hosted video on i.e. youtube.
Max-width, max-height are not working. Use fixed widths and heights for elements.
SVGs are poorly supported. They should be avoided and png should be used instead.
Fallbacks: Use Alt Text for images in case images are not loaded for security reasons

And the cherry on top of the cake is the complete lack of mobile signature support.

Mobile signatures are not automatically inherited from desktop ones. They are independent features which means if you try to send an email from your mobile gmail app there would be no email signature at all. You need to setup separately a mobile email signature in which a limited number of characters is only allowed. To overcome this challenge you can open your mobile web browser on your phone to access your email. From within the mobile web browser you can write/reply to emails and your desktop-defined email signature will be properly sent.