HTML Mailing List Best Practice
The sitekit channel emailer allows you to send HTML pages, plain text, or HTML so lists of email recipients. This broadcast content is unusual in that it has to be readable on many different mail clients and because it also need to get through varied mail client spam filters and security filters. This article describes the best practice for creating this content. Please be clear these are not specific to content broadcast from Sitekit CMS but are true for all content sent to mail clients.
The following is a list of 'rules' or best practice, following these in the creation of the HTML pages intended for broadcast will increase their readability, and increase their chance of being accepted and read on the majority of mail clients. The guideline are of most relevance to users that are creating a template and page specifically to be sent as a broadcast but some are also relevant for plain text and pasted in HTML broadcasts.
- Keep the associated stylesheet to a minimum (it may be ignored completed) instead any style information should be put on the element being styled, where this is not possible (e.g. for user editable content) the style info should be put in <style> tags in the body of the page – not the head. See extract below.
<td width=180 valign=top style="border-left: 2px dotted #525252;border-top: 2px dotted #525252;">content</TD> - Make sure the stylesheet (see above) doesn't reference any images these will typically not be applied but may be sent as attachments.
- Background images (even inline) can’t be used as outlook wont read them
- Background colors should be avoided as they wont be reliably/consistently applied, many mail client strip them out but retain font colours so you may end up with white font on a white background.
- If inserting any images for content make sure they are addresses absolutely e.g. http://www.domain.com/folder/image.png not /folder/image.png
- Generally as you'll have seen from the above points you'll need to create specific mailable layouts, stylesheets and content layouts in their own branch. It's very unlikely that you can mail out a standard page.
- Keep the overall size low. You can use this tool to check the size of what's been sent but it should be less than 512kBytes
- Try to ensure that the template for the page to be sent doesn't entrain any files such as google's analytics javascript file. Most mail clients will 'bounce' emails that have attached javascript files. The channel emailer will try to strip such content from any emails that it sends however depending on the format and location it may not be successful. If Scripts are inserted in a header variable block then an approach is to create your prospective broadcasts in their own branch, add a branch dependent scheme to the relevant variable block and strip out the scripts there.
- How the mail is received will primarily depend on the mail client so the textual content of the broadcast should contain character sets that are easy to translate for lower spec clients. A typical problem occurs with accented characters and MS Word specific content. e.g
- A word is entered like 'Fèis' however it is rendered on the received email (by the mail client) as either 'Fis' or 'F?is'
- Similarly if content is pasted into the page from a newer version of MS Word with items such as the MS Word dash '-' or the MS Word curled apostrophe ''' and again these are rendered as '?'
- The solution to both of the items above is to encode in the simplest format so use the native apostrophe's and hyphens rather than dashes and use 'è' instead of a pasted in 'è' etc.
Finally 3 cardinal rules
- Consider plain text users - not everyone will be able to recieve the HTML content, makev sure there's a palin text alternative, even if its just a link to the page in question.
- Keep the templates used for email broadcast simple and small - that way they run the best chance of being accepted by the widest spread of mail clients.
- Test it - always duplicate your mail channel and send the mail broadcast to the test channel first for validation. Try to make sure that the recipients on this test channel have a 'spread' of different mail clients.