The HTML coding standards and dilemmas or why is this so complicated? Part 1

What good is a standard if nobody follows it? I've asked myself this question numerous times and have come up with the earth shattering realization, wait for it—it's no good. In the wild west of HTML and CSS there seems to be no sherif in town; designers are faced with the perpetual problem of creating code based on a standard that may or may not be supported, rendering wise, by the receiving ISP/desktop software/mobile device. The problem can be summed up like this: "how can I achieve the most uniform rendering across the greatest number of email clients?"

The answer to this question confounds me as much as the problem: follow the standards. Why? Because we have to create a baseline that we can refer back to when our ship runs aground. If we code in non-standard non-compliant fashions we introduce ever increasing levels of complexity when attempting to diagnose a rendering issue. if for instance you code to the W3C (World Wide Web Consortium) standard then you are coding to the closest thing to a baseline that we currently have in the industry and can use industry tools in order to validate and check your code should you run into a coding challenge.

Pivotal Veracity's eDesign Optimizer incorporates a W3C code validation tool in order to help diagnose rendering issues. Most people look at the output of a code validation report and decide in two seconds that its more trouble than it's worth, but if you sit with the results for a few minutes, ignore the warnings and focus on the errors you'll find valuable information that may potentially solve your rendering issue.

One of the common rendering mistakes I've seen begins from the "top down". Most people start their html emails quite simply by declaring HTML, then maybe they'll remember the HEAD tags following by an opening BODY tag and then their content. Although this schema will work it isn't the preferred method here, and may in some quirky email client cause problems.

People seem to forget that an HTML email is a viable HTML document and should start with a DOCTYPE declaration. A code validation of that document would reveal that it's missing a DOCTYPE statement which informs a receiving server what kind of parsing to apply to the email:

Another way to think about the Doctype is like this: imagine sending a word doc to your friend and you removed the .doc ending of the file which tells your friend's computer which program to use when attempting to open the file. In most rendering cases the document will still render but this is about standards and long term sustainability. If you're going to design code that will travel the vast digital sea and wind up in a myriad of different inboxes you need to remember to cross your t's and dot your i's. 

it really is the small things when your coding that will make the difference down the road. Knowing that Outlook 2007 doesn't support FLOAT & CLEAR means you'll be better suited to creating code that although archiac and frustrating having to use tables for layout, will be compliant with the leading desktop and B2B email client's design requirements. Since it's the little things that matter we put over 6000 of these little things (data points) together in our Design & Rendering Guide which covers over 30 emails clients and the viability of CSS & HTML in those clients. In the next part I'll explore how content filtering is affected by your non-standard-compliant HTML. Stay tuned!

Cheers!
-Len Shneyder
Dir. of Partner Relations
& Industry Communications