Email vs Web HTML — Getting to Know the Key Differences
On the surface, someone unfamiliar with designing emails might think it can be approached in the same manner as web design. They are both written with HTML and CSS so they should be the same, right? Unfortunately, that is not the case. Here are just a few of the major differences that exist between email and web HTML/CSS.
The main reason why email and web HTML need to be handled differently is because of the difference when it comes to standards (or the lack thereof for email). An organization known as the World Wide Web Consortium (W3C) created rules/guidelines for the web which are referred to as web standards. In the early days of the web, browsers were competing against one another for market share and so they would implement vastly different functions and ways of rendering code. This made it so web developers would need to create multiple versions of the same website — one for each browser to ensure it rendered correctly. To combat this, web standards were created to promote as much consistency as possible no matter what browser you are viewing a website on.
In contrast, emails don’t share those same standards as implemented by browsers. For emails, each email client (Gmail, Outlook, etc.) has their own rendering engines that decipher and ultimately display the code in a human readable form. These different rendering engines differ in the HTML elements and CSS properties that they support. When you consider the vast number of email clients and different versions they run on, you can quickly see why a lack of email standards can cause frustration for a developer. A helpful tool to help combat this is Litmus, a company that provides a sandbox for email code to see how it renders in different clients. Simply copying and pasting your code into Litmus allows you to view how Outlook 2007 renders your code vs Apple Mail.
When it comes to styling the HTML with CSS, email and web couldn’t be further apart in how they are typically done. For the web, HTML is styled with CSS via an external stylesheet. Essentially, an entire file is dedicated solely to CSS and that file is linked to the HTML file in the <head>. Doing this is conventional and abides by the “separation of concerns” web development best practice. It keeps your code much cleaner and allows you to troubleshoot much quicker when you can swiftly narrow down where you need to look to resolve an issue.
For email, it is best to use inline CSS to style elements. This means that the CSS styles are placed right in the opening HTML tags themselves and it is a practice that’s frowned upon in web development. Emails must use inline styles because of their lack of standards across all email clients. Since some email clients choose to strip out internal styles in the <head> or linked external stylesheets, using inline styles is a best practice for emails to allow for the highest percentage of clients to render your emails properly.
The way websites handle layouts has improved drastically over time — especially in the last couple of years. The introduction to layout models such as CSS Grid and Flexbox has made laying out content a breeze compared to dealing with floats or the tables that were used in the web’s early days. Grid and Flexbox allow web developers to align content along a main and cross axis with a few short lines of code. Creating web pages comes down to having smaller boxes within bigger boxes that make responsiveness at different screen sizes easier than it has ever been before.
Email layout is much like web layouts in the early days — tables, tables, tables! This is due to the lack of standardization among email clients and how they render content. Tables are the most conventional way of creating emails and aligning certain cells to the left/right/center, setting padding/margin with empty cells, and more.
Using different kinds of fonts are a fun and unique way of making content stand out. When it comes down to fonts for the web, there seem to be endless options to choose from — especially by utilizing the extremely popular and free Google Fonts. By simply including a line of code in the <head> portion of your website or importing similar code in your CSS file, you gain the ability to use that font. People viewing your website will see the font too as their browser renders the code for them.
Unfortunately, emails are fairly limited in fonts that are safe to use. This restricts your ability to consistently choose a font that reflects your business’ identity and branding. For emails, it is best to stick to the “web friendly fonts” that come installed on most devices (Arial, Verdana, Georgia, etc.). Since there is no standardization and some email clients strip out stylesheets, it is best to stick to these safe fonts to ensure consistency among email clients.
These four differences just scratch the surface on the differences when it comes to email HTML and web HTML. Is your business having trouble creating consistent email campaigns? Need assistance with your website? We are here to help! Contact us today to learn more.