When building web pages, CSS is usually included in head of an HTML document and broken out into style blocks. This separates the stylistic elements from the HTML structure, allowing for a more efficient code base. It also ensures your content has consistent styling – one edit made to a CSS style block is one edit made to every single element associated with it.
Unfortunately, just about every email client will throw out any style block it happens to come across. The same goes for jQuery scripts.
That doesn’t mean CSS is of no use when building HTML tables. It just means designers can’t use style blocks to ensure consistent rendering. They have to use inline style.
Inline style is CSS style applied to a single element, and must be applied to every element you want it on. So, if you want all of the text in your data cells to have an Arial font-face, you have to add inline style to each
Fortunately, nothing really changes when using inline style versus a style sheet (other than being time-consuming) – style properties are written the same way they normally would, with the exception that they need to be written on one line.
The following is a snippet of the HTML table code used as the main example in the last post. In this instance, I applied inline style to the data cell that holds the headline text. The “Date” cell text has no style associated with it (with the exception of the HTML italics tags) to demonstrate how a web browser will apply default font settings if content is left untouched:
What it will look like in an email and on the web:
There are numerous style properties that can be used when implementing inline style in HTML emails, though designers should always err on the side of caution when choosing exactly which ones to use. A good example is the use of the padding and margin properties in data cells. Though they’re more basic style properties, padding and margin styles can be extremely unreliable – particularly in Outlook.
Experience is the best instructor when it comes to figuring out which style properties can be relied upon consistently and which can’t. There are some good reference materials available online, though. A personal favorite of mine is Campaign Monitor’s Guide to CSS Support in Email. This guide provides a list of common email clients, and which specific style properties each accept.
When in doubt – and it really pains me to write this – the surefire solution is usually the least efficient. It’s a contrary opinion to the one I hold on solving standard web page design problems, but there’s nothing standard about HTML email design. If there were, no one would be using tables and inline style. The entire process is inefficient from the get-go.
With that in mind, there’s no reason not to take an additional 15 to 30 minutes to make sure your code is cross-client compliant. If experience really is the best instructor, then one of the first lessons it will teach is that an extra half-hour spent during the first build will save hours of time dealing with the rendering issues your quality assurance department will inevitably find during testing.