If you are new to HTML, you should learn its basics here (about tags and main principles of HTML). Although tutorials published by W3Schools are targeted towards web design (not email), it‘s crucial to have at least basic knowledge of what HTML is and how it works. Once you understand that, you can move on with email HTML.
It‘s important to understand that HTML on websites and emails differ. Many HTML and CSS properties used in modern web design are not supported in email. Email programs like Outlook 2007 and 2010 use Microsoft Word (yes, a word processor) to render HTML. So you’ll need to go a bit old-school here and code everything with tables (<table>, <td>, <tr> tags will have to become your best friends).
Email design best practices
For best results, you’ll want to:
Keep your design simple: avoid drop shadows, fancy fonts, rollovers, and other interactivity
Emails should be 600-800 pixels maximum width (600px is recommended). This will make them behave better within the preview-pane size provided by many clients.
Design for simplicity. Use grid-based layers and avoid complicated elements that require HTML floats or positioning.
Assume images will be initially blocked by email clients or that certain images—background images, for example—will completely fail to load.
Don’t design an email that’s essentially one large, sliced-up image. While this kind of email looks pretty, it performs poorly. Remember that there is a huge number of different email clients that render email differently. Sliced-up images will be displayed differently (for example with unnecessary space). Another reason - low text-to-image ration can cause spam filters to be triggered.
Be careful when choosing fonts. Use email-safe fonts or widely adopted custom fonts.
Don’t forget about the phone experience! Is your email readable at arm’s length on a small screen? Will the images slow their load time on a mobile device? Are your links easy to press with a thumb?
Email HTML best practices
Much like with design, there are best practices to follow when coding HTML email.
Code all structures using the table element. For more complicated layouts, you should nest tables to build complex structures.
Use tables for layout and basic inline CSS for formatting
Use element attributes (such as cell padding, align, and width) to set table dimensions. This forces a box-model structure.
Keep your CSS simple. Avoid compound style declarations (IE: “font:#000 12px Arial, Helvetica, sans-serif;”), shorthand code (IE: #000 instead of #000000), CSS layout properties (IE: slot, position, clear, visibility, etc.), complex selectors (IE: descendant, child or sibling selectors, and pseudo-elements). Remember – you need to use inline CSS. All Omnisend's default templates contain inline CSS automatically.
Give all Images Alt Tags (a.k.a. Alt text). Most email clients block images by default. In some cases, instead of showing the image, the email client will instead display the ALT text. This is definitely handy, especially in cases where an email design is predominantly composed of images. The ALT text can help communicate the message even if the images cannot.
Use bulletproof buttons instead of images. It allows you to build buttons with code instead of images. You can reliably swap your GIFs, PNGs, and JPEGs for HTML and CSS. Why? Because many email clients block image-loading by default. In other words – your images of buttons might not be visible.
Use only absolute links for images, and host those images on a reliable server (which could work under load spikes).
Avoid elements that require Flash or JavaScript. If you need a motion in an email, a .gif is your best bet.
Account for mobile-friendliness, if possible. Use media queries to increase text sizes on small screens and provide thumb-sized (~46x46px) hit areas for links. Make an email responsive if the design allows for it.
Test, test, test. Create email accounts across various services and send emails to yourself. Or you can do so with an email testing service, like Litmus.