EmailElements - Blogging all about HTML Email Standards, CSS and XHTML

CSS Hover in HTML Email... is it possible???

2008-01-22T14:08:00.001-05:00

I had an idea today, would it be possible to use the CSS hover technique to create some kind of JavaScript rollover replacement for Email. I wasn't looking for your typical link hover effect or a mouseover effect on an image, my concern was more along the lines of: you have a link, and when you mouse over it can you expand the area to show more text beneath it.

This could be quite useful when you consider it's implications in scenarios like the following: You have a paragraph long intro to a story that ends with a "more" link leading you to the full version of the story somewhere on the web. What if vertical resources were sparse and you needed to condense this? Not only would you be able to condense it using hover, the whole paragraph then becomes a clickable link to the full story... or perhaps even more useful... rollover text ads that expand to show skyscrapers and then contract again to just the text, allowing you to perhaps include more ads while in actuality using less space!

So with this in mind I set about testing all the clients and browsers I could with the following VERY simple code.

I know right away this won't work in Gmail, since hover cannot be applied inline and Gmail cuts out the style block. But it's still worth an experimentation anyways since I found Gmail simply defaulted to show the entire content and so even when it breaks the user is still getting essentially the full experience.

My results for browsers were as follows:

WINDOWS XP SP2
DESKTOP CLIENTS
Working
Outlook 2003
Outlook Express
Thunderbird
Eudora
Incredimail
Opera

WEB CLIENTS - Internet Explorer 7 & Firefox 2
Working
AIM Mail
Excite
Hotmail Live
Hotmail Classic
Yahoo Classic

Not Working But Degrades Well
Gmail

MAC OS X 10.4
DESKTOP CLIENTS
Working
Entourage
Mac Mail

So as you can see these are totally encouraging results! This basically means that no matter what the scenario you use this technique in, even if it fails the user will still see your content.

Coding an HTML Email in 3 Easy Steps : Part 3

2008-01-11T11:30:00.001-05:00

Ok we're finally ready to code! We've looked at the email from the "big picture" angle, and we've looked at the proper ways of cutting up the images. So now we have an images folder full of pretty pictures and a blank document open in our favourite text editor (UltraEdit for me incase you're wondering). So how do we start? Well, I usually like to start by having a pre-defined template that serves as the base for my emails. It has the basic structure and I can use it to start coding from right away. This works for new emails, however if you're simply creating a new edition of an older email, much like a monthly newsletter, I always always ALWAYS use the most recent version of code. The reasons for this are two-fold. One, there is much less coding needed if the format is always similar, it's mostly just an update the copy and links job and two, I am always updating code to stay ontop of developments in email clients. So the last version used will always have my most recent fixes and mods and I won't have to worry about updating an older template that wasn't using newer techniques.

Here's an example of a code snippet I use as a base template for starting with:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<body>
<style>
#cssshell a
{
font-family:Verdana,Tahoma,Arial,Helvetica,Sans-Serif;font-size:12px;color:#CE482F;
}
#cssshell td
{
text-align:left;
}
</style>
<table width="600" border="0" cellspacing="0" cellpadding="0" id="cssshell">
<tr>
<td> </td>
</tr>
</table>
<a name="bottom"></a>
</body>
</html>

I'm not going to get into very precise coding techniques, as the purpose of this series is to give you overall method rather than individual technique. However a few notes on the code above might be helpful, so...

As per my earlier article regarding doctypes, I now place a doctype at the top of all emails to ensure code is following standards in Outlook and Express
Always enclose the email in an open and close HTML set of tags, this lowers spam score
No need for the head tag, and always ensure the style block is placed BELOW the body tag
The overall link style is used because some clients will rewrite links using their default font/color
The td alignment fix was used for issues in Hotmail live wherein a centered table would force all internal cells to be aligned center as well, I have yet to test if newer versions of Hotmail Live still cause this problem, but as a safegaurd I always leave this in
A complete table, with an ID of cssshell to ensure the style block is used on this table only, if you use overriding styles with no ID attribute you run the risk of styling the entire interface of a webmail client

You're now ready to start coding and laying out tables to your hearts content. I always use the ideology that less is more when I code for email. Keeping code size down will allow you to keep bandwidth costs down for your clients as well as speed up delivery. Even a few kb's lower in file size has massive implications on mailing lists with millions of recipients.

So as we start coding I always find it’s helpful to have the PSD open as well as your new HTML document so that you can reference the layout as your working, it gives you a good idea of how to look at your code in a visual way and you can start to see how everything will translate into table cells, speaking of tables...

Tables, it’s all about tables, sure they aren’t the latest web standards but it’s the only way to layout an email easily while ensuring it works in as many clients as possible, so use them instead of divs to place your content. I know it feels wrong... but believe me... you'll get much better results.

Using CSS inline is the way to go when coding emails. They work in all email clients as long as you avoid some pratfalls and unsupported elements. They also provide the most consistent branding by locking down things like font size which normally can be very sporadic if you leave it up to the <font size=""> tag and attribute. I know there is a school of thought in user design that we should make the font size and color open to user preference, by using style techniqes that utilize percentage rather than a fixed pixel width. I'm not here to argue one case against the other... but I use pixel height as a precise measure because I look at emails as being a very precise, final medium. They are not like a website, they do not change or get updated on a regular basis. They get sent once and that's it, a person can look at it the first time and the hundredth time and they technically should still see the same thing. The only other medium that follows those rules is print, and print uses a fixed font height. I realize that I did just argue for one side over the other... but well... it's my blog :)

Coders - Always style table cells that enclose text with at least the font-family and font-size. Set line-height to normal unless you need specific line spacing as different web clients tend to interpret specific values differently. Always apply inline styles to links and wrap the link text itself in <font color=""></font> tags

Well that about covers the basics for how to code an email from scratch. I hope you enjoyed it!

Cheers

Coding an HTML Email in 3 Easy Steps : Part 2

2008-01-09T13:57:00.000-05:00

So part one dealth more with big picture and at the end I discussed taking a wider view of the email and deciding what to do on a few key points. Ofcourse describing what to do isn't as useful as actually checking out a visual example so I've gone ahead and included a quick email mockup below and highlighted key things to look for when you do that big once over at the end of step one. This will really help you figure out how to slice up your photoshop document so that you are getting maximum effect with minimum filesize.

This is the finished product on the right, so let's start deconstructing it bit by bit.

MACHINE TEXT
In the example to the left originally the words Win a cool prize pack... were graphic text, in this specific scenario the words were in a very unique font and therefore could not utilize machine text, but for the sake of example if they were in Arial or Helvetica or Verdana they could most likely take advantage of machine text. So when you first open your PSD do a once over to see if there are any areas which can use this technique.

SLICE AREAS
Highlighted in green are the areas that would make the best candidates for “slicing”. They are all pretty obvious and can usually be determined by whether the final product will be an image or use code/machine text. Sometimes you will encounter drop shadows, these work just as a regular HTML background, you would slice 1px of height from a vertical drop shadow, use it as a cell background at which point it would then auto-repeat inside an expanding table cell. It is useful to note however, that if you are expecting a large recipient base to be using Outlook 2007 it would be best to avoid this method and opt for one big dropshadow image.

CSS BORDERS
It is a little hard to see in the example, but just above and below the main content area are two red highlighted areas. These consist of simple 1px lines which can be achieved merely by setting either a border-bottom:1px solid #FFFFFF or border-top:1px solid #FFFFF. This then ensures that even with images turned off, this element of the design will still be seen.

CSS PADDING
One final thing to look for when scoping the PSD is, where can the email take advantage of CSS padding? In the left you can see multiple areas highlighted in yellow. These areas indicate places where using CSS padding will allow you to position elements properly within table cells. For example in the left column in the main content area, there is no need to use pixels to space out content when a simple padding:20px; tag will push all elements inside that cell 20px inward away from all the edges. Same with the black border running around the entire email, all that needs to be is one big table cell with a black background that uses equal padding to push the entire table within it away from its edges.

Ok so we have now given the creative a good once over, and we've decided where we need to slice. You can then begin cutting up the PSD in Photoshop by creating slices using the slice tool. Make sure you cut as close to images as possible, as we can generally use padding or borders to space things out later, this cuts down on image size and let’s us do more in the code instead.

It may also help at this point to be sure and give your slices relevant names. This makes it easier once you save them by allowing you to tell which image came from where, what type of graphics it is (ie:image, header, text, etc...) and it also saves time having to rename everything later.

CUT IT CLOSE
The graphic on the right shows the incorrect way to cut an image (red highlight) and the correct way (green highlight). Notice how the green highlight excludes all the extra space, letting the code do the work for us.

That's it, you're finally ready to save for web. When I get ready to start saving the images I like to keep the following in mind:

Generally images with multiple colors and less complexity (with regards to straight lines) are better served being saved as jpg’s where as flat text or portions that have few colors within them are better served by being a gif
Remember this is email, not the web, people want quick downloads, so make sure you cut down file size as much as possible while still retaining the best image quality you can, generally try and keep the masthead imagery looking sharp whereas smaller images within the email can suffer more as they are not responsible for initial impact

IMAGE TYPES
Notice how the images in the example have been divided up. The masthead had multiple colors and the least amount of complex lines so it was best served as being a jpg whereas the rest all worked more efficiently as gifs.

Check back for part 3... coding!

Cheers

Coding an HTML Email in 3 Easy Steps : Part 1

2008-01-08T16:25:00.000-05:00

Awhile back I decided to write out all the processes I go through when I sit down in front of a computer and get ready to code an email from scratch. I think I pretty much have my thought process down to a science now and I think it might be helpful to share it here, so over the next three days I'll post my overviews of each step along with the best practices that I use to ensure that I get the most readable email possible.

Part one is all about the pre-production phase. It really helps to take a look at your creative as whole and go over how exactly you are going to slice that gorgeous design up to get the best reproduction possible in Gmail, Hotmail, Outlook and not Lotus Notes :) It's a short step and doesn't involve any technical knowledge, but I can't stress enough how important this first step is, as everything that happens in your code will come from the decisions you make in phase one.

Let's get right to it then:

FOR COMPATIBILITY
Even the best email campaign designs can fall flat if they are not coded properly. What may look stellar on the drawing board, and come to life further in Photoshop layers, can end up looking like an incoherent mess in the preview pane. With some background knowledge and adherence to best practices you can ensure that email recipients get the most out of our emails.

JPG’S ARE THE LAST RESORT
Sounds simple sure, but a lot of times Account Managers or Project Managers send you, the coder, jpgs. These are generally no good for coding. We need Photoshop Originals for three reasons:

We need to get the best quality possible for images and the only way to do that is to ensure the source we start from is of the best quality possible.
We must ensure that we can turn elements “on” and “off” using layer visibility incase there are elements that are obstructed.
If no copy deck exists, the Photoshop document becomes the source for our copy, and we need to be able to copy-and-paste from it into our HTML code.

Designers - Ensure your layers are grouped relevantly and named appropriately so that they can be easily understood by a coder

SEEING THE BIGGER PICTURE
Again it all sounds very simple, but this is actually the most important step of the three. Give the overall design a once over and try to make at least some general decisions about the following:

What areas should remain as imagery and what areas can utilize machine text
Where will your slices work most effectively to reduce the amount actual pixels used in an image
Are there any straightforward simple lines that could benefit from using CSS borders instead of a stretched 1 pixel image
Where can you utilize padding so that you don’t include any unnecessary pixels in your slices or use the 90’s old school technique of pixel-spacers

Designers - Try to ensure that any text that can be machine text is, and is not anti-aliased, since generally a client approves a design flat, not a coded flat, and differences in subtleties such as anti-aliasing on text can cause disagreements

That's it for part one. Tomorrow I'll follow-up some graphical examples and we'll get into part 2, which involves cutting up the design and getting ready to code, and then we'll end with part 3... the actual coding!

Cheers

Using DOCTYPE in an Email

2007-12-20T14:47:00.001-05:00

The other day a co-worker brought up a good point, what happens when you include or exclude a DOCTYPE from an email code? I hadn't really given the issue much thought seeing as how most web clients simply strip out anything above the HTML element anyways, but I decided it was atleast worth a test... and I came back with a different take on the whole concept. DOCTYPE makes a big difference in some major clients, most notably Outlook 2003. I'm going to post my full review soon along with my test case, but as a brief rundown I've compiled the brief list below testing this code in both standard and quirks mode. You can clearly see the difference in both in Internet Explorer, unfortunately no difference is visible in Firefox, but as I said, this was merely an initial test.

On Windows XP SP 2:
Affected
Outlook 2003
Outlook Express

Rendered in Standards Mode Regardless of Existence of DOCTYPE
Thunderbird v1.8 (not conclusive as it may have been using FireFox's quirks mode, requires further tests)
Eudora v7
IncrediMail XE
Opera 9

I'm thinking that since the Outlooks are the only 2 desktop solutions that use IE as a rendering engine this makes sense.

On the Web in Internet Explorer 7:
Affected
None

Rendered in Standards Mode Regardless of Existence of DOCTYPE
Gmail
Hotmail Live and Classic

Rendered in Quirks Mode Regardless of Existence of DOCTYPE
AIM Mail
Excite
Yahoo New and Classic

The standards mode rendering seemed a bit off to me, since Gmail strips the doctype, but it must be applying its own standard to all code within the email preview area.

On the Web in Firefox 2:
Same as above, but results will obviously appear differently since FireFox's quirks mode is significantly different that IE's.

I went ahead and made the assumption from these two tests that all the webmail clients will behave the same in all browsers, leaving it up quirks mode to define AOL, Excite and the two Yahoos, and defining a doctype for Google and the two Hotmails.

On a Mac
Affected
Mac Mail

Unaffected
Entourage

I am guessing Mail must be similar to Outlook in that it uses Safari to render HTML emails. I'll have a more in-depth review coming up after the holidays, but from what I can tell so far, putting the DOCTYPE in doesn't actually do harm, if anything it helps ensure you're rendering to compliance spec in Outlook and Mac Mail... however the downside is since all web clients seem to disregard it or use their own DOCTYPE standard you have to pretty much code for both. Don't you love coding for email? :)

Cheers

XHTML Compliant JavaScript Form Validator

2007-12-18T14:05:00.000-05:00

So I have been working on a javascript form validation system for awhile that would be suitable to be dropped into just about scenario. Sure there are already solutions out there like the TMT validator, but it doesn't validate XHTML.

During my day to day I work on alot of .NET projects where there are loads of back-end validations going on. Besides the fact that I have to deal with server rendered form elements I also I personally try to avoid using the built in JavaScript validation that MS provides. It's buggy.. and very.. Microsoft.

So I needed something that would validate XHTML Transitional as well as be simple to implement in any coding environment, and voila, a week later here it is in it's very beta version. I tried to think of every validation that might ever be required on a web form. It has plenty of simple customizations, such as specifying particular country validations on phone numbers and postal codes, as well as allowing a couple of methods for error display. All of these customizations can obviously be expanded by any coder with moderate JavaScript understanding, so this might be a good base for others to start from.

Check out the XHTML Compliant JavaScript Form Validator here

If you can think of any way to optimize this, without bulking up the code too much, or any validations that might be a necessity please let me know or leave a comment.

The instructions are on the same page as the form itself, so please read through them to get the proper syntax for implementation into your own projects.

Enjoy!

My top 4 tips for image usage in email

2007-12-17T10:05:00.000-05:00

Bigger isn’t better when it comes to email. Heavy graphics contribute to slow load times, increased bandwidth costs and a less than satisfying user experience. That’s why optimizing the images you place in your marketing email is an important piece of the creative puzzle.

With that being said, here are my top 4 tips for image usage in HTML email:

File format
JPG’s are best for larger graphics that consist primarily of images, such as a masthead photograph. GIF’s are perfect for smaller items which contain less colour complexity and/or text – graphical buttons, for example.

Check out your template before you cut your images and figure out which file formats are better based on the rule above.

Avoid saving anything in a format other than JPG or GIF. Though you might be tempted to save an image as a PNG for the sake of maintaining opacity percentages – it’s not a good idea. They work, but your file size will be huge. Instead, try to find a workaround or a different way to lay out the design.

Reduce the size of large images even further
Split up graphical items when possible. Say, for example, you have a masthead that is 600px wide. 400px of that masthead is just an image, and 200px is a flat colour background with stylized text on top of it. If you save the entire 600px image as one JPG you will not only end up with a larger file size than needed, but your stylized text will appear degraded and blurry.

On the other hand, saving the entire masthead as a GIF will increase file size exponentially and will only allow the image portion to display 256 colours max.

Your best bet would be to cut the image into two sections; GIF for the portion with text and JPG for the rest. This will significantly reduce the bandwidth required – and it bears remembering that a bandwith drop of just 2-3kb can equal a considerable savings when you’re sending to a list of 100,000+ subscribers.

Saving images in Adobe Photoshop
To start with, you’re better off using Adobe Image Ready when it’s time to save your final images for production. In either Photoshop or Image Ready, be sure to use the "save for web" feature. The tweaks available in that save format allow you to really cut down the file size and play with quality/colour palettes in much finer detail than just your average Save As dialogue box. If you work with other graphic programs, you can explore their options for prepping images for web.

Quality vs. Quantity in a JPG and a GIF
Feel free to run down the quality of JPGs that are nothing more than an image (eg, no text overlay). You might think you need the best possible quality on that beautiful image but, in fact, the difference between saving a JPG at 80% quality in Photoshop as opposed to 40% is usually negligible. Tinker with it to see how low you can bring down the percentage before the image becomes distorted. A jump from 80 to 40 may only have minimal visual impact but can save you a lot in the file size department.

My number one piece of advice for when you sit down to turn a beautiful design into a functioning, low file size email?
Take a step back and figure out what needs to be an image and what doesn’t. Often using simple HTML and inline CSS can replace the need for an image. Consider this... You have a header that consists of nothing more than a 300px x 200px brown background with white, Arial text on top.

You have two options:

Save the header as an image. Following rule number one, you’ll be saving it as a GIF to ensure text quality. This will cost you 1-3kb in file size. It will also mean that, with images turned off, that header will be unreadable by default in most of the email/webmail clients on the market today. Ouch.

Use HTML and inline CSS to ‘recreate’ the brown background and white text on top. You may not get Anti-aliasing, or an exact font match, but you will save on file size and get your message across even with images-off and, in most cases, that’s more important.

Welcome!

2007-12-14T13:58:00.000-05:00

Hello one and all to my new blog! The purpose of this bad boy is to keep tabs/track of the latest and greatest in the world of coding for email.... with a little bit of CSS and XHTML throw in for good measure.

You might be thinking, coding for email, how hard can that be? A div here, a float there, maybe a table in-between? Well, with little to no background it's guaranteed to be a slippery slope of high spam scores, codes that look nothing like the creative and emails that degrade into anything but a reinforced brand awareness message.

I've been working with email now for the past 2+ years and it requires a coder to not only stay on top of the latest developments with email clients (ie: new Gmail, Outlook 2007) but also find new an innovative ways to ensure that no matter who is getting your email, they're seeing exactly what you intended them to.

With that in mind, I'll be using this space to share with you all the cool tips and tricks that I've developed in my toolkit, as well as some handy suggestions for best practice coding... PLUS on top of all this, I do occasionally enjoy coding a website or two and that has given me the ability to become a bit of a CSS/XHTML fan. So if I discover any handy tips, you'll be sure to see them here as well.

Check back soon for my first "real" entry, my top tips on how you can save images to maximize impact and minimize bandwidth.

Cheers