Things that will not work, or not work if cross-client rendering is the business requirement (based on your code snippet).
- html5
- media queries
- binding styles with classes & ids (everything should be inlined – with a programmatic tool or coded by hand)
- CSS paddings (limited support)
- CSS margins (limited support)
- paragraphs
- max-width CSS rule
If you want cross-client template, follow these guidelines. Those are roughly from the top of my head, since I coded emails professionally a few years ago, but I don't have some "hard" tests or links to back all of this up.
- Use HTML 4.01 doctype, and its rules.
- Responsive (RWD) e-mails are really next-level advanced stuff. I would not recommend that until you really grasp what is going on in rendering engines (lots of testing). For now stick to fluid-layout, which can be achieved with table structure as explained here. Also media-queries does not work cross-client, I would drop them.
- Margins, paddings have mixed support, use them only on
td elements, and always double up with cellpadding if you can.
- Avoid short-hand CSS declarations. Instead of
border, use border-width, border-style, border-color. Width should always go first.
- Do not use paragraphs (
p tags), leverage td's to the fullest, by using cellpadding and cellspacing, which works everywhere.
- Aligning content (text, images) is done easiest with
align and valign attributes on td tags. When used correctly can help immensely with coding any layout.
- You can use this CSS guide and Can I Email for quick fact-cheking, as mentioned by @cloned (there was no Can I Email back in my days).
- Get yourself in the mindset: the year is 1994 and all you have at your disposal are tables (lots of 'em), images, default fonts, and inline CSS :) You can get a long way with just that.
- Firefox was helpful for me during development, because its rendering engine is close to what Thunderbird would output on screen.
- If you can sneak in proper rendering of some custom font, or animating gif, or interesting responsive behaviour, that is great, but do not count on it. It definitely will not be cross-email-client experience, and the clients/managers you work for (if you have them) should be aware of that. This is "progressive enchancement" for email rendering :)
- Most email clients will do horrifying things with your template, like mangle your code to the point of it being unrecognizable, adding custom ids, overwriting classnames, adding own custom styles or custom classes, striping all the head section, etc. Part of it has to do with security, another part with rendering engine. That is why you should rely on tables and inline styling most of the time, and keep whats in the
head to absolute minimum that you know will work in the programs (email clients) you are targeting.
In short this is really deep topic, the understanding will come to you, as you gain experience with testing results and adjusting your code. You should invest in testing preview software (you mentioned Litmus). I have used Email on Acid, which also is great. You should use it to preview results in different email-clients, not to send your campaigns/emails.
Most important:
If you are changing your code, test it right away (Litmus/Email on Acid) to gain an insight how it renders in every email client. This is tedious and takes time, but after a few times you will know exactly what you can do, and what the result will be. Isolate what you are testing, and do it often.
Second most important:
Define what pool of email clients you are targeting. This should be done in agreement with your client/manager (if you have them). You wrote, that you want template that will work in "all email clients". That is just not realistic. There are too many of them.
I was testing in more than 60 configurations, when I was coding a new template. Thats 60+ screenshots to check for each test. You need to narrow down to a pool that is "good enough" and can reasonably be tested. This should be checked with the statistics of the subscriber list, and the visible email addresses being used by newsletter subscribers.
For example: if 50% of subscribers use Outlook 2007 and the rest use Gmail, then you know you need to target and test in those two clients. The rest is just "a bonus". Of course you don't always know that, so you should include most popular clients as well. Use public stats provided by Litmus, or someone else to determine what is "popular" at this time.
Another thing is that you may or may not need to include in your testing specific web-based email clients related to geographic area, for example gmx.de, or onet.pl, etc. Most of them have their own rendering engines developed in-house. Some of them even have special rules that apply to newsletters sent by them to their users. In that case you should be able to get written documentation how the newsletter should be prepared (special tags, formatting, etc).
Also think about some more obscure email clients, what if someone uses Kindle or Apple Watch to read emails? What should they see? Some of this type of clients use "text-only" version of a newsletter, so you should also prepare text-only version, if HTML-version cannot be displayed, or a user specificaly blocked HTML and requests text only.
