Codificación de documentos para correo HTML

http://www.sitepoint.com/ Empowering Web Developers Since 1997 By Tim Slavin Tim is an Internet expert who publishes ReachCustomersOnline.com, a Website with how-to information for businesses and the designers, programmers, and others who support them. How to Code HTML Email Newsletters By Tim Slavin June 16th 2006 Reader Rating: 8.9 Note: This article has been updated by the author and republished, replacing the original article from 2004. The HTML [1] email newsletter is a very successful communications medium for both publishers and readers. Publishers can track rates for email opens, forwards, and clickthroughs, and thereby can measure reader interest in products and topics; readers are presented with information that's laid out like a web page, in a way that's more visually appealing, and much easier to scan and navigate, than plain text email.

Yet coding HTML email can be a mix of misery and pain for programmers. The biggest pain is that so many different software tools are available for reading email, from desktop software such as Eudora, Outlook, AOL, Thunderbird, and Lotus Notes, to web-based email services such as Yahoo!, Hotmail, and Google Mail. If you thought it was difficult to ensure the cross-browser compatibility of your web sites, be aware that this is a whole new game -- each of these email software tools can display the same email in vastly different ways. And even when these tools do display an HTML email properly, accounting for variances in, for example, the widths at which readers size their windows when reading emails makes things even trickier. This article describes the results of my own hands-on experience creating HTML email newsletters for clients, as well as bits of technical information from the Internet. This is actually a revision of an article that was written and published on sitepoint.com in 2004, and includes new, up-to-date material that will help you ensure that your HTML email newsletters meet the requirements of today's email clients. Step 1: Use HTML Tables for Layout That's right: tables are back, big time! Web standards may have become the norm for coding pages for display in web browsers, but this isn't the Web, baby. Mail clients are light years behind the eight-ball in terms of CSS [2] support, which means that we must resort to using tables for layout if we really want our newsletters to display consistently for every reader (see the reading list at the end of this article for some excellent resources on CSS support in mail clients). So put your standards-compliant best practices and lean markup skills aside: we're about to get our hands dirty! The first step in creating an HTML email is to decide what kind of layout you want to use. For newsletters, single column and two-column layouts work best, because they control the natural chaos that results when a large amount of content is pushed into such a small space as an email. A single-column layout typically consists of: a header, containing a logo and some (or all) of the navigation links from the parent web site to reinforce the branding and provide familiarity for site visitors intra-email links to stories that appear further down in the email a footer at the bottom of the email, which often contains links that are identical to the top navigation, as well as instructions for unsubscribing Two-column emails also use a header and footer. Like a two-column web page, they typically use a narrow, side column to house features and links to more information, while the wider column holds the body content of the email. Promotional emails follow similar rules but contain much less in the way of content and links. They often include one or two messages, and sometimes make use of one big image with small explanatory text and some links below the image. All of these email layout possibilities can be created easily, using HTML tables to divide up the space into rows and columns. In fact, using HTML tables is the only way to achieve a layout that will render consistently across different mail clients. This is the approach that I use to create HTML emails: For a two-column layout, create one table each for the header, the two center content columns, and the footer -- that's three tables in all. Wrap these tables into another container table. Use the same approach for single-column layouts, but give the content table one column. This approach is especially suitable if the design of your email contains images that are broken up over multiple table cells. Otherwise, a single table with td rows for its header (with colspan="2" if the design uses two columns), content, and footer should display fine in all but Lotus Notes email software. Use the attributes within the table and td tags to control the table's display. For example, setting border="0", valign="top", align="left" (or center, if that suits the design), cellpadding="0", cellspacing="0", and so on. This primarily helps older email clients to display the email in a (barely) acceptable way. Even if the design of your email doesn't include a border around your table, you might find it helpful during development to set border="1" to help with the debugging of any problems that arise with the internal alignment of tr and td tags. Change it back to border="0" for testing and production. While this approach might offend purists who prefer to code using the latest standards, it is the only approach that's viable at this point. But the fact that we're using tables for layout doesn't mean we need to resort to old-school methods entirely. For example, no matter how poorly Lotus Notes displays HTML email, you should never have to resort to using the font tag. There are some caveats, though; let's take a look at styling our text next. Step 2: Add CSS Styles Did I say CSS support was poor in mail clients? Well, it is. But you can (and should) still utilize CSS for the styles in your email once your nested table layout is in place. There are just a few things to watch out for. Here are the steps that I use. First, use inline styles to store all of your style information, as shown here: <p style="color: red;"> This includes table, td, p, a, and so on. Do not use the CSS style declaration in the HTML head tag, as you might when authoring web pages. Google Mail, in particular, looks for any style in the email and (helpfully) deletes it. Also, don't bother using the link element to reference an external style sheet: Google Mail, Hotmail, and other email software will ignore, modify, or delete these external references to a style sheet. For your container table -- the one that houses the header, content, and footer tables -- set the table width to 98%. It turns out that Yahoo! mail needs that 1% cushion on either side in order to display the email properly. If side gutters are critical to your email's design, set the width to 95% or even 90% to avoid potential problems. Of course, the tables inside the container table should be set to 100%. Put general font style information in the table td, closest to the content. Yes, this can result in repetitive style declarations within multiple td cells. Put font style definitions into heading (e.g. h1, h2), p, or a tags only when necessary. One way to make up for this redundancy is to use CSS shorthand wherever possible (the TRBL acronym will help here: Top, Right, Bottom, Left). For example, consider the following markup: style="margin-top: 10px; margin-right: 5px; margin-bottom: 10px; margin-right: 0;" Instead of the above code, use this format (remembering the TRBL rule): style="margin: 10px 5px 10px 0;" Use divs sparingly to float small boxes of content and links to the right or left inside a table's td cell. Google Mail, for one, seems to ignore the CSS float declaration (yet Yahoo! and Hotmail cope with it just fine). Sometimes it's better to code a more complex table layout than to rely on the float declaration. Or, since it's all too easy to clutter up an email, ask your designer to put the floated content in the narrow side column instead. Flaky support for floats is one issue that may cause an email design to be reworked. While divs appear to be barely useful, spans appear to work almost every time, because they're inline elements. In some cases, spans can be used for more than just coloring or sizing text: they can be used to position text above or below content. Note that some email delivery services will unpack style definitions to make them more explicit and, therefore, more readable by all email software. For example, the CSS shorthand style="margin: 10px 5px 10px 0;" may be expanded into the long style declaration shown earlier. Test each email and look to see what happens to the email code. Start with CSS shorthand because, in the worst case, it appears to work well with all email software. Step 3: Adopt Best Practices Knowing that you've created valid HTML email using the guidelines I've suggested is only part of the solution -- there are several best practices that you should follow to ensure that your email is well received. The next step is to test your HTML email in a variety of email clients. Often this will identify problems that require workarounds. The first test tools to use are the Firefox [3] and Internet Explorer web browsers. If the email displays well or perfectly in both browsers, there's a good chance that testing the email in Outlook, Yahoo!, Google Mail, and other services will reveal only minor problems. Once the email appears fine in those two web browsers, use an email delivery service to send the email to a range of test email accounts. Ideally, this should include accounts with the Yahoo!, Hotmail, and Google Mail services. The test accounts you use should, of course, be determined by the domain names in the mailing list of people who will receive the email. For example, if there are no AOL subscribers on this list, it's probably a waste of time and money to set up, and test with, an AOL email account. Here are the most common code tweaks that I've found necessary during this test phase: Sometimes, a switch from percentage widths to fixed widths is needed. While this is not ideal -- because readers can and do resize their email windows while reading -- sometimes, using a fixed width is the only way to have a layout to display properly in multiple email clients. If there's a spacing issue with the columns in the email design, first tweak the cellpadding and cellspacing attributes of the HTML tables. If that doesn't work, apply CSS margin and padding attributes. HTML spacing works better with older email software. Image displacement can occur when a td cell is closed right below an img tag. This is an ancient HTML problem. Putting the </td> tag right after (on the same line as) the img tag eliminates the annoying and mystifying 1-pixel gap. In addition, the following best practices are recommended: Avoid using JavaScript [4]. Most email software will disable it anyway. If an image is sliced up and spread across several HTML table cells, test the email using many test accounts. Sometimes, it might look great in Outlook but be shifted by one or more pixels in Hotmail and other services. Also consider making the image a background image on a new HTML table that encases all of the table rows and columns that would display parts of your background image; this often achieves the same effect as slicing an image up, but uses less code and can provide better results (see below). Use the target="_blank" attribute for the a tags, so that people who read with webmail services don't have the requested page appear within their webmail interface. For background images, use the table's background attribute instead of using CSS. This works more consistently across email software than other potential solutions. Store the email images on a web server -- preferably in a folder that's separate from your web site's images (for example, in a folder called /images/email), and don't delete them. Some people open emails weeks or months later, the same way people use bookmarks to return to web sites. While a 1x1-pixel image can be used to force spacing to create a precise email layout, spammers often use 1x1-pixel images to determine if their email has been opened. As such, using this practice will increase the likelihood that your email is classified as spam. Similarly, avoid using a large image "above the fold" in the email. This is another classic spammer practice and may cause your email to be interpreted as spam. As part of testing an email, also include a test for potential "spamminess". SpamCheck [5] is a useful service that highlights issues that might cause an email to trigger spam filters. While it comes bundled as a tool called Site Build It, that is available for purchase, the online version of SpamCheck is a free service, and no purchase is necessary to make use of it. Once the HTML email has been tweaked so that it displays well in your test email accounts, the next step is to go through a checklist. For example, verify the following: Does the From address display properly (as a name, not a bare email address)? Is the subject line correct? Is the contact information correct and visually obvious? Does the top of the email display the text, "You received this email because ... Unsubscribe instructions are at the bottom of this email."? If it's important for you to know absolutely everything that could go wrong with the way your HTML email is rendered, try a service like Browsercam.com [6]. For a small hourly fee, you can post the email as a web page on a server, then point Browsercam at the page. Browsercam will take snapshots that show how the email appears on a wide range of browsers and operating systems. While the snapshots don't show how email software will display an email, many email clients use web browser components to display HTML email, so Browsercam is a good way to increase the chances that you will spot any rendering issues. Step 4: Code for Google Mail and Lotus Notes It seems obvious that a relatively new service like Google Mail, which uses a web browser to display email, would display HTML email perfectly and support the latest web standards. Unfortunately, this is not the case. Because Google cannot control the contents of the emails it displays, the service providers have had to take steps to ensure that their application displays properly regardless of the quality of the HTML or CSS in which emails are written. As a result, Google Mail is a new web mail service that acts like an artifact of the early 1990s, when web standards were primitive. It takes some work, but it is possible to crack open a Google Mail page and see just how convoluted the services approach to rendering HTML email actually is. For one thing, Google Mail deletes the CSS styles contained between any style tags, no matter where they appear in the email. And fonts displayed within HTML tables -- the only alternative to using styles -- have the odd habit of appearing larger than intended, no matter how the HTML email is structured. Here are some techniques that appear to work well in Google Mail and older email software: Define the background color in a td cell with bgcolor=, not the CSS style. As noted above, use the background attribute in the td cell for background images instead of using CSS. One side-effect of this approach is that the background image can be made as tall as needed -- if the content used in your email template is likely to vary in size, using an extra-tall background image in this way allows the height of the email shrink or expand, depending on the height of the copy, from one email to the next. If it works better, use the padding declaration to control margins within a td cell. The margin style does not work in these cells, but padding does. If you need a border around a td cell, keep in mind that Google Mail displays a border around a td cell when it's defined in a div, but not when it's defined as a border style in a td tag. If you need a light-colored link against a dark background color, put the font definition in the td cell (so it applies to p and a tags equally) then add a color: style to the a tag. If the p and a fonts appear to be different sizes, wrap the a tag in a p tag. Google Mail aggressively uses the right-hand column of the Google Mail user interface, which squeezes the HTML email into the center panel. Be sure the padding style in the content tds is set to 10 pixels all round, so that text does not hit against the left and right edges. When testing an HTML email with a Google Mail account, it's likely that you'll find that one or more font styles are missing in the td, h1, h2, p, a, and other tags. Inspect every font carefully to make sure Google Mail displays the fonts correctly. Besides Google Mail, there's another, less obvious hazard a programmer faces when creating HTML email: Lotus Notes. Many large corporations continue to support and upgrade their Notes installations (as of 2004, IBM reported that 95 million people used Notes). Unfortunately, it's impossible to tell which companies use Notes. The best approach is to follow the guidelines described in this article -- the more primitive the code, the more likely it will work well, if not perfectly, with Notes. That said, it's quite possible that Notes will introduce to your HTML email quirks that are almost beyond belief. For example, the software can convert images to their proprietary formats, or simply ignore flawless basic HTML in one email, but display other HTML fine in another email. A trial version of Lotus Notes is available for download if you need to test your mail in Notes -- see the resource list at the end of the article. Here are a few tips that will help you convince Notes to display your HTML email properly: As we discussed previously, use a container table that contains all the internal layout tables (for example, for the header, content, and footer). This keeps the email together in one chunk of HTML, so pieces of the layout are less likely to wander when displayed in Notes. Create a gutter around the container table by setting the width to a percentage and/or using a cellpadding of at least 5. Use absolute URLs to images stored on a web server. You can't do much about Notes converting images, but using remote images might help. Intra-email links, using named anchors, rarely (if ever) work in Notes. It's simply best to avoid links that jump down the email to a specific piece of content. Avoid colspans in your HTML tables. Notes -- especially its earlier versions -- can deal only with basic table layouts. Be sure that your td cell widths are accurate. Unlike web browsers, which automatically set all cells to the widest-defined width, Notes sizes each td cell based on its defined width. Centering an email layout usually won't work in Notes. Email layouts generally have to be left-aligned. Summary Many people who receive email prefer HTML over text for a number of reasons. For programmers, though, the task of creating an HTML email that will display consistently appears both simple and horribly complex. This article has described many of the issues and strategies for creating markup that will work across email software. What's the best idea to take away from this article? If there's a choice to be made between a simple email design and a more complex solution, simplicity is always the safest bet. Further Reading These resources offer valubale information that will help you if you want to learn more about coding HTML email. MailChimp Weblog [7] This is an excellent weblog devoted to email marketing, delivery, and coding issues, published by MailChimp to support its email delivery business. The blog provides a lot of useful information, tools, free email templates, and links. The developers annotate the code in their free templates, and have tested the templates with multiple email programs. Cracking open these templates provides an excellent way to study how to code for a wide range of email software. HTML Email Tips for Web Designers [8] A useful, barebones list of guidelines for creating and sending email. The free email templates [9] also are great samples to study, because the code is heavily commented and has been tested against a broad range of email software. And, finally, the Resources [10] page includes some great links to best practices, as well as other resources. CSS Support in HTML Emails of Hotmail, Yahoo! Mail, and Gmail [11] by Xavier Frenette This is excellent research that shows style-by-style results for how these three webmail services display CSS. A Guide to CSS Support in Email [12] Campaign Monitor, an email service provider, has taken Xavier Frenette's excellent work documenting CSS performance in a few email clients and expanded it to include Gmail, Hotmail, Yahoo!, and Windows Live Mail. It also covers Outlook 2003, Outlook Express, Lotus Notes, and Thunderbird on the PC, as well as Mail, Entourage, and Eudora for the Mac. \">The "Secrets of HTML Email" Series [13] Some of this information is old but a good piece on Lotus Notes is offered. Lotus Notes Trial Software [14] This page offers free downloads of the latest Lotus software, which is handy if you need to test an email with the Notes client software. Browsercam [15] This is an excellent service for testing how compatible your web pages are with a variety of web browsers and operating systems. For email, it simply shows you all the warts in your HTML code, even if your email works fine in Notes, Google Mail, and other difficult email software environments. SpamCheck [16] This decent, free online service tells you about the "spamminess" of your email. You also should look for an email delivery service that provides this sort of spam check. CSS-Discuss: HTML Email and Using Style [17] DadaMail Software [18] CSS and Email, Kissing in a Tree [19] This excellent CSS-only approach to HTML email was published by A List Apart. NOTE: The author has written an update to this article, posted at the Campaign Monitor blog, Optimizing CSS presentation in HTML emails [20]. How HTML Code Affects E-Mail Deliverability [21] A decent overview that describes how different email services view the HTML you include in an HTML email. You can't address every problem directly (for example, creating a clear boundary between the HTML and text versions of your email is a problem for your email service provider, if you use one) but it helps to know what happens.

Topics Before You Code Domain Names Hosting Site Planning Legal Issues Privacy and Trust Design and Layout Usability and Information Architecture Accessibility Design Principles Design Practice Design Tips & Tricks Software Tutorials Flash Tutorials Client Side Coding HTML & XHTML Tutorials CSS Tutorials JavaScript & DHTML Tutorials XML, XSLT & Web Services Server Side Coding ASP & .NET Tutorials CGI & Perl Tutorials Coldfusion Tutorials Java and J2EE PHP & MySQL News & Interviews PHP & MySQL Tutorials PHP & MySQL Reviews and Apps Server Side Essentials Apache & IIS Configuration Site Strategy Community Content eCommerce Site Marketing Traffic Analysis Search Marketing Other Promotions Sell Your Services Get Started Find Clients Work Smarter