A How-To Guide to Validating HTML for Email0
HTML validators are invaluable tools for people that write code. They can let you know if there are any errors present that might cause display issues and give you some clues for debugging. Validators do this by checking your code against a specification, or a set of rules for the language that your code was written in. These specifications make up what is commonly referred to as “web standards.” The trouble is that most email clients don’t support web standards and instead only support a hodgepodge of HTML and CSS. Validating HTML for email can be tricky–read on for our how-to guide.
One of the most popular validators is the free one maintained by the W3C, or World Wide Web Consortium. Litmus’ comprehensive spam checking service also uses the W3C validator and reports back the warnings that the validator returns:
Since most email clients don’t follow web standards and there are no email-specific standards in place, this means that validating the HTML you’ve written specifically for email can be tricky business. Due to these variances in HTML support for some email clients, you might find yourself using hacks, deprecated elements or unstandardized code to get your design rendering correctly.
HTML validators work best for email when you use them to check for syntax errors, unclosed tags, or orphaned tags. When attempting to validate HTML coded for email with a web validator, it’s pretty common to see errors and warnings that are confusing. Which ones matter? Are there any you can ignore?
First, a word on doctype
HTML validation works by comparing your HTML to a set of standards or rules, called a DOCTYPE. DOCTYPE is a document type declaration, and is usually placed at the beginning of your HTML file to tell the validator which set of standards to check your HTML against:
In the case of web development, it also tells the browser which rendering mode to use. The problem with using DOCTYPE with email is that some clients strip out the DOCTYPE or apply their own. If you don’t include a DOCTYPE in your HTML file, the W3C validator will use the HTML 4.01 Transitional Document Type. They also maintain a list of recommended DOCTYPEs. Generally speaking, I recommend using the HTML 4.01 Transitional or XHTML 1.0 Transitional when validating HTML for email.
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
Also, Campaign Monitor has written up a nice post about the use of DOCYTPE in email.
Warnings vs. Errors
Once you’ve run your HTML through the validator, you’ll receive a list of warning and errors. Errors are generally more critical than warnings, but sometimes errors can be ignored depending on context and usage.
Issues with tags
Pay close attention to errors stating that a start tag or end tag have been omitted, or when an end tag has not finished. Examples of these errors are “end tag for TABLE omitted,” “end tag for element A which is not open,” or “end tag for P which is not finished.” These are critical, but easy to fix. The validator should indicate the line of code in your HTML that the error was found, so you can easily locate and fix the problem. The validator will display errors for all types of standard tags and elements (TD, TR, TABLE, DIV, A, STRONG, etc.)
All HTML elements should have an appropriate closing tag to be considered valid, and having valid (and properly nested) closing tags are critically important with HTML email. However, there are a handful of elements that are considered empty elements or self-closing tags (namely BR and IMG in email). To be considered valid under an XHTML doctype, these tags require a trailing slash (/) at the end of the tag:
<img src=”image.gif” height=”10″ width=”10″ border=”0″ />
In an HTML doctype, will produce a warning (usually “NET-enabling start-tag requires SHORTTAG YES”). Both approaches work fine with HTML email, but if you’re concerned you can clean this up before re-validating your code.
Warnings and errors you can ignore
There are several types of messages that are generally safe to ignore. A common error you might see is “there is no attribute BACKGROUND.” While BACKGROUND is a perfectly valid element for using background images in an email (and the only way to ensure background images display in Gmail), it’s considered a “deprecated” element and thus invalid under certain specifications. An element is considered deprecated when it is slated for removal from the specification when new or better ways of doing the same thing are introduced. For example, U (for underlining) was deprecated when CSS was introduced and it is now preferred to use the “text-decoration” property. Deprecated tags are still supported, and in some cases an email client may only support the older, deprecated element.
Links that include web analytics or conversion tracking may trigger warnings such as “reference to entity for which no system identifier could be generated” or “cannot generate system identifier.” These are usually due to an unencoded ampersand present in the URL. You may choose to encode the ampersand, but I usually don’t find that these cause problems.
If your messaging platform or ESP uses specialty tags or proprietary scripting, these will also trigger validation warnings that appear as “Element x undefined.” For example, Campaign Monitor uses the tags
to indicate where the unsubscribe link should appear in your email. Chances are you’ll have to ignore these warnings in order for your email to work properly after it’s been sent from your provider.
Troubleshooting and debugging
Keep in mind that errors can cascade, meaning that one error at the beginning of your HTML may trigger more further down the document. Fix one or two errors toward the top of your code and revalidate to see if cascading errors were fixed in the process.
The validator will also show explanations for each of the errors, but these can be confusing due to the use of technical language. The W3C has a page with explanations for many errors, which can be helpful.
A couple folks have created alternative validator tools that include warnings for HTML and/or CSS elements that aren’t supported by email clients. Check out fractal or the inline styler, which converts your embedded CSS to be inline and also gives you a report on your code’s compatibility with major email clients. Keep in mind that these tools do not check for unclosed tags or other standard errors, so it’s a good idea to also run your email through the standard W3C validator.
Curious as to how this can fit into your overall production workflow? Use the results from the State of Email Production report to help benchmark your own process, identifying opportunities for improvement and using this evidence to make a compelling argument for more resources or process streamlining.