HTML and CSS in Emails: What Works in 2024?
Arguably, one of the most exciting aspects of web development in recent years has been a significantly more consistent level of support for new HTML, CSS, and ECMAScript (JavaScript) standards amongst web browsers. However, the same cannot be said for email clients despite the introduction of fresh features such as media queries, flex, rem units, and more.
Create Email Templates with Postcards Email Builder
Postcards: Email Template Builder
Understanding the constraints of email clients and their varied degrees of CSS support is crucial if you want to style your emails with CSS. This is a quick guide to email assistance for CSS:
- Utilize inline styles: Email clients need inline styles, not web sites, which frequently make use of external stylesheets. The “style” tag must be used to directly incorporate your CSS rules in your HTML code as a result.
- Ensure simplicity: It’s recommended to adhere to fundamental CSS properties like font size, color, and background color because not all of them are supported by email clients. Useless complicated characteristics like shadows, gradients, and animations should be avoided.
- Utilize tables for layout: Email design still makes extensive use of tables, despite the fact that modern online design mainly relies on CSS for layout. To organize your email layout, use tables rather than floats, flexbox, or grid.
- Test your emails to make sure they display properly on all platforms given the variety of email clients and devices available. You may check your emails for CSS compatibility with the use of tools like Litmus and Email on Acid.
- Employ fallbacks: It’s always a good idea to have a fallback in place in the event that an email client doesn’t support a specific CSS attribute. For instance, you can offer a fallback font that is more commonly supported if a client doesn’t support web fonts.
These recommendations will help you generate appealing and efficient emails that work with the majority of email clients. To ensure optimal compatibility, don’t forget to test your emails frequently and modify your CSS as necessary.
With Postcards Email Builder you can create and edit email templates online without any coding skills! Includes more than 100 components to help you create custom emails templates faster than ever before.
Free Email BuilderFree Email TemplatesLet’s take a look at some of these features and how we can make them work for all email clients, in 2024.
Internal CSS
Undoubtedly, one of the most annoying aspects of creating HTML email templates is having to declare styles for every individual element within its style attribute (for example <element style=”style:value;”></element>), otherwise known as ‘inline CSS’.
Luckily, internal CSS (i.e. styles written within a <style> element) has more support now. Internal CSS is way more efficient since it enables us to combine selectors and write less code that’s more readable.
According to Can I Email, internal CSS works in 84.85% of today’s email clients, but there are a few rules that must be followed in order to make this happen.
Luckily, all of the rules can be complied with by using two <head> elements/inserting the <style> element into the second one. See the example below…
<head>
…
<style>
…
</style>
</head>
However, while the days of styling using ancient XHTML attributes (e.g. <element align=”center”>) are over, support for internal CSS isn’t as high as we’d like it to be, so many email developers still choose inline CSS depending on the target audience.
It’s worth noting that some features (e.g. media queries and custom fonts) can’t be ‘inlined’, so a common approach to coding emails is to use internal CSS for progressive enhancements only and inline CSS for everything else (unless you’d be willing to forfeit custom fonts and cool layouts, of course).
It’s not an ideal approach, but it is what it is.
With Startup App and Slides App you can build unlimited websites using the online website editor which includes ready-made designed and coded elements, templates and themes.
Try Startup App Try Slides AppOther ProductsNote: external CSS (i.e. the <link rel=”stylesheet”> method) only works in 21.21% of today’s email clients, which is a huge shame because it somewhat rules out creating email design systems.
Media Queries
Internal CSS allows us to use media queries, a necessary component of responsive design. Without media queries, emails can end up looking dreadfully linear, and while there’s absolutely nothing wrong with that from a minimalist viewpoint, a vertical design won’t be the right choice in every scenario.
Media queries only work in 75.75% of modern email clients so we recommend designing responsive layouts that degrade into vertical layouts very gracefully.
Additionally, there are some rules to remember…
- Avoid nested media queries
- Limit conditions to screen, min-width, and max-width or omit them entirely (@media { … })
As mentioned before, media queries can’t be used inline. They must be used within a <style> element, so you’ll very likely be using at least some internal CSS even when inline CSS is your default approach.
Postcards helps designers create emails and then automagically outputs code that makes them work in all modern email clients. Internal CSS? Inline CSS? Both? Postcards takes care of everything while you focus on design.
Flexbox or Grid Layout
Unsupported CSS isn’t the only bane of creating emails. Traditionally, HTML <table> has been the backbone of email, but must we still do it this way in 2024? Can we not use the modern <div> element with Flex or Grid?
<div> is supported in 100% of today’s email clients, so no issues there. Grid, however, isn’t well supported at all, although display:flex surprisingly works in 84.85% of email clients (it actually has better support than media queries!).
However, flex’s related CSS properties (flex-wrap:, align-items:, flex-direction:, justify-content:, etc.) have terrible support — tables are the better choice.
Naturally, this rules out the possibility of using semantic HTML elements (e.g. <article>) too, which is a shame for readability and accessibility reasons.
Combined with a lack of full support for internal CSS, this means that in practice email development hasn’t really advanced at all and tools are very much needed if we want to avoid the excruciating task of manually coding emails using extremely old HTML/CSS.
While tables are hard to write (and read), don’t worry, Postcards absolutely loves tables and codes them for you.
Custom Fonts
Although custom fonts are somewhat cosmetic, beautiful typography is the best way to make emails more intriguing, but the easiest method of embedding custom fonts (<link rel=”stylesheet”>) only has 21.21% support in today’s email clients.
Naturally, this only leaves the @font-face approach, which sadly isn’t well supported either (36.36%). However, both approaches afford us the opportunity to suffix font declarations with fallback fonts, so there’s no harm in using @font-face regardless. It’s a relatively simple approach and font embedding services such as Google Fonts* and Adobe Fonts will still work.
@font-face {
font-family: Roboto;
src: url(“https://fonts.gstatic.com/s/roboto/v...
}
selector {
/* Google font, fallback, fallback */
font-family: Roboto, Arial, sans-serif;
}
*Oddly, Gmail has the worst support for custom fonts, which includes their very own Google Fonts!
If you don’t want to use a font embedding service or host the font files yourself, you can Base64-encode the fonts, making it easy to embed them into the email itself.
Here’s what that @font-face might look like (simplified):
@font-face {
font-family: Roboto;
src: url(data:font/ttf;base64,AAEAAAATAQAABAAwR1BPU+Df...
}
All-in-all, custom fonts aren’t well supported, however it doesn’t take a lot of work to implement them for the email clients that do support them. In the world of email development, this is a rare win.
Postcards can embed any of the 1,358+ Google Fonts, with multiple fallbacks that closely resemble your ideal typeface.
SVG Images
SVGs typically have lower file sizes than their bitmap equals, and when served inline, they don’t delay the loading of the email. Unfortunately, SVG has terrible support. It’s fallback approach (i.e. <picture> with PNG/JPG fallback) is even worse.
Generally speaking, I would avoid SVG for now and stick with PNG/JPG images. If you’re using Postcards it’ll compress them anyway so you don’t have to worry too much about emails loading slowly. In any case, it’s best to avoid excessive imagery anyway, not only because of slow devices but also so that users don’t have to scroll too often when using handheld devices.
As a final note on image formats, it’s worth mentioning that WebP images are unusually supported in 97.05% of modern email clients. They’re safe to use.
What about [x] feature?
We’ve now covered the most in-demand features in email development, but that certainly doesn’t cover all of the limitations that modern email clients still impose today. For example, text-decoration:, a CSS ‘feature’ that you’d expect to work everywhere, in fact doesn’t work in iOS and Android versions of Gmail when using a non-Gmail email address. For email clients that do support text-decoration:, you’ll need to explicitly declare it — it’s not automatic.
We must consider every HTML/CSS feature carefully because even some of the most basic ones don’t work when certain (sometimes odd!) rules aren’t followed:
- CSS border: (100% support, but the border width can’t exceed 8px in Windows Outlook)
- CSS !important (91% support, but they must begin with a space and be in lowercase)
- CSS border-radius: (91% support, but the shorthand slash /doesn’t work in some cases)
- CSS background: (100% support with a quite a few rules, although nothing too concerning)
Here are some HTML/CSS features that you’ll want avoid though, at least until there’s more support:
- CSS box-shadow: (58% support)
- CSS aspect-ratio: (33% support)
- CSS :calc() (7% support)
- CSS rem units: (53% support)
- CSS Variables: (06% support)
- Semantic HTML (low support and unsupported tags are usually stripped rather than converted to <div>)
Parting words of wisdom
As you can see, email development is still very complicated even though modern features are being introduced. Can I Email is an incredible resource for researching specific HTML or CSS email features, but it can be time-consuming.
Alternatively, you can skip the migraine and use Postcards’ drag and drop builder to create the email design you want without worrying about which HTML/CSS features work. Postcards knows so you don’t have to.
