Introduction to Responsive HTML Email
Whether you’re an aspiring HTML email developer or you’ve somehow ended up with an HTML email project you need to manage, coding emails properly can seem pretty difficult at first glance.
HTML Email Development vs. Web Development
If you have experience with HTML and CSS for website design and development, you’ve likely heard of W3C Standards as a guideline for checking your website’s code. For the web there are only a handful of browsers or rendering engines, such as Google Chrome, for developers to keep in mind while developing along with the help of W3C. In HTML Email Development, however, there are no development standards and over 80 Email Clients taking up the majority of the market share to develop for.
Testing HTML Email Code
So, how can we make sure that all of our HTML Email designs render properly on 80+ email clients? Instead of attempting to test email clients manually by sending ourself emails using a free tool like ‘Putsmail’, there are a select few software services that can give us previews of the email clients. Services ‘Litmus’ and ‘Email on Acid’ allow us to add our HTML Email Code to their web applications while providing an output of screen shot images showing how our email looks on Mobile, Desktop, and Web email clients totaling upwards of 99% of the market share. These services come at a hefty price though, nearing $100 per month for each service respectively.
All of the HTML examples, code advice, and the HTML Email Mastery Course on this website come with the email client testing stamp of approval after extensive HTML email template design testing using one of the two services. To get a complete list of all of the email clients used to test the HTML email code, see the Email Client Marketshare list.
HTML Email Best Practices
Now that we’re aware of the testing needed for HTML email designs to make sure they render properly on email clients, lets’ go over a few best practices for your designs before getting out your text editor.
What’s the Best Email Template Width?
When working with a responsive email template the width of the design will be determined by the device width for mobile users, but how wide should the layout be for tablets, desktops, and web email clients?
There are many different email clients to consider when determining the width of your design but one of the most commonly used is Gmail for the web. Considering that many users will access gmail on their laptop or desktop computer via the web, it’s important to recognize that at a certain browser width Gmail will start to cut off the edges of the email design, as will other clients, to make room for the vertical menu on the left side of the screen. At a reasonable browser window width using a laptop, at around 1200px Gmail will provide an email body width of about 640px, and other clients behave similarly. With this in mind we’ll design out HTML Email Templates at a width of no more than 600px to be sure we can see all of our design. Not to worry on smaller screens though, since we’ll be making our designs responsive.
HTML Email Accessibility
Similar to designing for the web, it’s important to take accessibility into consideration while developing for people using screen readers to access the information included in your emails. Given all of the table, table row, and table data HTML tags in email code, a screen reader would tell the user a bunch of useless information without having the right HTML attribute to prevent it. That attribute is called “role” and it’s value is “presentation”, letting the screen reader know that the table in question is for design purposes and not information that needs to be read. So role=”presentation” should be included in all table tags when designing for accessibility.
Don’t Include Text in Email Images
When someone opens their email it’s possible they’re settings are such that images won’t display unless they select ‘display images’, which is also known as having image blocking on. For users with image blocking, it’s important that you include Alt text for the image with the HTML alt attribute so when the image doesn’t display there is text describing the purpose of the image. It’s also important not to design emails that can only convey the message through images that include text in the graphic itself for this same reason, so having a steady diet of content through traditional text in the email is preferred with images or gifs adding flare to the message but not delivering it.
Use Safe Fonts for Outlook
One of the best resources for adding custom fonts to your emails is by using Google Fonts where the font style can easily be imported into an HTML document. Most email clients will render the Google Font but there are a handful that will not, including Outlook versions for Windows. For this reason it’s good practice to include safe fall-back fonts when adding a Google Font to your HTML email template design. There is, however, a specific way to prevent the fonts so Google Fonts can be used in certain email clients without Outlook falling back to it’s default ‘Times New Roman’ font though. The Outlook specific font needs to be added to the email code to the same element via a ghost table using Outlook Conditional Comments, this way you can have the ‘Lato’ Google Font in non-outlook clients and the similar ‘Arial’ font in Outlook as an example.
..continue to the next lesson: HTML Email Doctype.
