HTML e-mail

Overview for Proofreading

HTML e-mail layouts are divided into sections, and created in tables separating the images & content sections.

The copy within the body of the e-mail is entered as live text.

Building an e-mail

Live text is webpage copy that has been entered as HTML code rather than displayed as part of an image file.

The key benefit of HTML live text over non-HTML alternatives is that content can more easily be customized or reformatted for different browsing devices, it is in a web safe font, able to be seen even if images are turned off & read by spam filters to identify if it’s a legitimate e-mail, it can also be picked up by screen readers & assistive technologies.

Live text moves/adjusts according to where it’s being viewed, & there is minimal control over where it may break or cause widowed words, therefore re-ragging or running back words is not always a request we can accommodate.

Live HTML Text

E-mail Preview

An e-mail is one scrolling page viewed in an e-mail client’s preview window

There are no pages or page numbers

This is the preview window in which the proofs are printed to file & saved as a PDF for the client to view

A live e-mail does not have pages, just one scrolling preview

Creating a proof of the e-mail

Header & footer envelope information

This is the envelope information associated with the e-mail & is not part of the actual e-mail design

“To” and “Sent” information is due to the timestamp of when the proof was made & is not associated with the e-mail itself

Spaces in the header & footer are due to the PDF print output, not the display of the e-mail

Symbols & special characters are HTML elements The envelope information including the subject line is entered in the

StrongMail delivery system as hard text & is not a HTML element Using symbols increases the risk of an e-mail getting marked as Spam

Subject lines & special characters

The hedge language & layout for RWC templates is legally approved, & we do not make changes.

Outdated hedges on markups are automatically updated to the most recent version & no variations are made other than link color changes to match custom branded templates.

Hedge

With the release of Outlook 2007 & 2010, Microsoft switched to Microsoft Office Word as a rendering engine for both reading and composing e-mails in Outlook from its previous versions that used Internet Explorer to view e-mails.

Microsoft’s decision to avoid using a browser to render HTML ignores standards-based e-mail design & allows less control for e-mail designers over how HTML e-mails are rendered, & Adobe Acrobat proofs created from these e-mails do not accurately display the way the e-mail is actually viewed in the preview pane.

Outlook 2010 Rendering

Outlook 2010 does not support: Animated Gifs, JavaScript & Flash Background images & shadowed

edges Forms Wrapped text Justified text Borders on images Middle text alignment alongside

images Font rendering CSS Support CSS positioning & image float <div> width properties with

background colors (i.e.: 100% background table width with background color)

<td> Padding values & failure of the tops of cells to line up properly resulting in cut off background colors. i.e.: white lines

Formatting: Word applies its own print based formatting that applies automatic page breaks and gaps in the layout of long e-mails with a lot of content

Outlook 2010 adds a one pixel gap under (or over) every image inside a table cell

Ignores image resizing Automatic letter spacing

Questions?