The campaign leveredges Twitter to rally the web design community around the issue, and a realtime mosaic of the tweets can be viewed at fixoutlook.org. The site is worth a visit for this feature alone!

Further reading

Microsoft to ignore web standards in Outlook 2010 – enough is enough

In the following example IE7 considers the HTML comment to be the first child, and therefore my selector will fail.

CSS:

li:first-child { font-weight:bold; }

HTML:

<ul>
    <!-- IE7 thinks this comment is the first child. Oops! -->
    <li>The li:first-child selector should make me bold</li>
    <li>I'm the second child</li>
    <li>I'm the third child</li>
</ul>

Let me explain what I mean.

Instead of naming a div based on where it appears within my layout, I try to name it based on the content it describes. For example, rather than markup a site’s header as:

<div id="header">

I mark it up as:

<div id="branding">

and instead of:

<div id="footer">

I choose:

<div id="siteinfo">

The idea is that in the absence of meaningful, semantic HTML elements with which to markup content I use the most descriptive CSS id name I can think of.

How ironic then, that the new HTML 5 header and footer elements describe content based on where it appears on the page, rather than what it means.

Update 08 Dec 2007: I thought it was worth mentioning that the branding/siteinfo naming structure isn’t one I came up with myself – it is suggested by Andy Clarke in his book Transcending CSS.

For most web designers, especially those who work solo, a custom built content management system is still a tall order. Fortunately there are numerous commercial and open source content management systems available, which offer a practical and affordable means of wrangling content. However, a “one size fits all” content management system that doesn’t address a site’s specific content requirements can introduce as many problems as it solves.

One page, one blob

The easier a content management system (CMS) is to configure and use, the more restrictive it is likely to be. HTML and CSS offer a rich toolset for describing and presenting all kinds of content, yet most CMSs cannot be configured to address the myriad types of content a content editor needs to display. Instead, the content editor is given the ability to modify just one “blob” of content per webpage. This format suits the majority of webpages, but assumes that the content editor is happy to have just one block of plain text per page, or that they are comfortable styling text with regular HTML tags, or a ’simplified’ variation such as markdown. For the novice, HTML is hardly child’s play, and trusting a client to write compliant markup is optimistic to say the least. That’s where WYSIWYG (What You See Is What You Get, pronounced “wizzywig”) editors come to the rescue, and that’s when problems start to creep in.

The WYSIWYG problem

The WYSIWYG editor is at the heart of most modern content management systems, if not by design, then because web designers install one themselves. They are used as a “cure all” by CMS developers and web designers alike, because they provide content editors with a powerful interface for styling content, using a toolset that replicates the desktop word processors with which they are already familiar. The two most popular WYSIWG editors are TinyMCE and FCKEditor. Both use Javascript to enhance a regular HTML textarea, and do so via a menu of buttons similar to that found in Microsoft Word. This probably sounds ideal – a website’s content editor can take total ownership of their content, styling it in any way they please. But content editors are precisely that: editors. They are not designers, and shouldn’t have to – or be allowed to – make decisions that affect the design of their content. Sadly, this is exactly the power that WYSIWYG editors put at their fingertips.

Tinymce in all its glory. Watch your client destroy your layout in mere seconds!

Let loose with a WYSIWYG editor a content editor can mix and match font size, face and color, and even add tables, images, background colors, and emoticons to a webpage. If you think they will have the self control to exercise restraint, think again. Even the ability to alter the appearance of text can have disastrous results. I have seen a content editor use a WYSIWG editor to set body copy in 16 point, 12 point, and 10 point at various places on the same page, and in three different typefaces. Another client inexplicably changed the color of list items to exactly the same blue used throughout the site to indicate hyperlinks. The impact such misguided decisions have on usability and design should be obvious.

Of course the blame doesn’t lie with the content editor. They don’t have training as a graphic designer, nor can we expect them to grasp the subtleties of interactive design. The problem is that WYSIWYG editors mix the description of content (headings, lists, blockquotes) with its design (typefaces, colors, and point sizes). Web designers have long understood the importance of separating content from presentation, but WYSIWYG editors snatch that separation away from us.

Dial it back

Fortunately, most WYSIWYG editors allow you to limit their functionality to suit your needs. This can either be done using a CMS’s administration interface, or by editing a configuration file. When faced with a WYSIWYG editor I dial its functionality right back, leaving only the core set of tools needed to effectively describe content. Does a content editor need to specify background colors for text? Of course not. The size of text? Nope. Paragraph alignment? Uh-uh. Tables? Lets not even go there. I don’t even let a content editor underline text. Why? Because underlined text looks like a link.

Headings (h1, h2 etc), bold, italic, ordered lists, unordered lists, blockquotes, and hyperlinks: these should provide sufficient scope to describe most types of content. Let your regular CSS stylesheets style the output, and you’ll ensure the rendered content fits seamlessly with your existing website layout.

The copy and paste problem

WYSIWYG editors present another problem I haven’t touched on yet. Usually a website’s copy isn’t typed directly into a content management system, it is composed in a word processor, then pasted into the CMS. When this happens the formatting of the source text is brought across too, warts and all. Despite your best efforts to limit your client’s ability to style content, with one keystroke they can inadvertently bypass your safeguards. There are two solutions to this problem. The first involves education. Both FCKEditor and TinyMCE include a ‘paste as plain text’ button, that gives users the option of stripping all formatting from text as it is pasted into the WYSIWYG editor. The only problem is that your client needs to remember to use the button. The second option is more pro-active. Both FCKEditor and TinyMCE have a configuration setting that forces content to be pasted as plain text.

What about web standards?

A criticism often leveled at WYSIWYG editors is that they produce spaghetti code. In part, this is true. The only way a WYSIWYG editor can define the color of text, for instance, is by applying an inline style to your markup. But if you limit the WYSIWYG to a few core capabilities, as I suggested above, there is far less that can go wrong. The developers of WSIWYG editors are mindful of the need for standards compliance, and I have found that in most cases it isn’t hard to get both TinyMCE and FCKEditor to generate tidy markup.

Other options

Building a CMS from scratch is a huge task. I ought to know – most of my websites are powered by a CMS I built myself. Unless you are a competent programmer and have a heap of time up your sleeve (or just enjoy a challenge!), building your own CMS isn’t an option I would recommend lightly, but the advantages of the DIY route certainly pay off in the long run.

Building your own CMS gives you absolute control over how the software functions, allowing you to customize it to your own needs with fine grained control. When something breaks, you know how to fix it. If you want to add a new feature to the CMS, you just go ahead and add it, rather than submitting a feature request to the software vendor and crossing your fingers.

Another option to consider is XStandard, a WYSIWYG editor that touts its standards compliance and accessibility features. The big drawback I can see with XStandard is that it requires the content editor to install the XStandard application on their local machine. By contrast, a javascript based WYSIWYG editor makes your website editable from any computer sporting a modern web browser.

Whichever approach you take to content management, so long as you give careful thought to both your client’s needs and the pitfalls of giving them free rein, it is possible to strike a balance that keeps everyone happy. Giving clients the ability to edit their website’s content, and creating beautiful, standards compliant websites needn’t be mutually exclusive goals.

Validation is something I only do on my own work now.

Bowman was part of the team responsible for the 2002 redesign of Wired News using web standards and CSS. Wired News was one of the first major standards compliant sites, and helped pave the way for the web standards revolution. So for Bowman to state that validation of client websites is no longer an important consideration is quite an eye opener.

What designers like Bowman advocate is a pragmatic approach to web standards, an acknowledgment that validation is not practical in every situation. Non-compliant Content Management Systems and authoring tools, multi-developer teams and (let’s face it) poor attention to detail can all result in the production of invalid markup. When balancing the benefits of standards compliant markup against the time and cost required to overcome these obstacles, sometimes compliance is going to lose out.

I personally believe that web standards should be a cornerstone of any modern web design project. However, I also understand that given a limited timeframe and budget in which to produce a website, a certain level of compromise is sometimes inevitable, and perfectly acceptable. Consider the following common validation slip ups:

• Images missing an alt attribute
• Unencoded ampersands
• Empty <p></p> or <div></div> elements
• Uppercase XHTML tag and attribute names

All of these oversights will result in XHTML validation warnings or errors, but presently will not impact on the way a document renders or functions in a web browser. Neither do I expect these errors will cause significant problems in future browsers – I find it hard to imagine a web browser refusing to display a page simply because it contains an empty paragraph element.

Certainly if I notice any such errors during the development of a site I fix them straight away. However if I identify the errors at a later date, or they creep into the site during a content update, then I question the importance of correcting them immediately. In the past I would have dropped whatever I was doing and rushed to squash the offensive (but invisible) validation error, almost as a matter of personal pride. Today I am more inclined to add it to my to-do list for the next occasion I’m working on the site. In the meantime I know that both my client and the site’s user base will be totally oblivious to the ‘problem’.

In this discussion it is important not to lose sight of the benefits that standards based design undoubtedly brings to our workflow. Quicker development cycles, faster loading pages, simpler site redesigns, and improved search engine visibility are just some of the gains to be had by producing semantic and standards compliant documents. But our job as web designers is not merely to produce sites that adhere to the standards of our industry. There are also technical, budgetary and timeframe requirements to be factored in. By taking a pragmatic approach to validation it is possible to meet these demands without abandoning our commitment to web standards.

Now, it’s not too surprising that a website designed a few years back makes liberal use of tables and transparent spacer gifs for layout, but inexplicably all of the gifs have been given an img alt attribute of – you guessed it – “spacer.gif”. By itself this won’t cause display problems, but the href provided for the spacer gifs is also incorrect, meaning that the browser is unable to display the images. In combination these boo-boos cause Firefox to render the image alt values on screen, messing up an otherwise clean layout.

I’m surprised no one who works on the Exxon website has noticed this problem. I guess they all use Internet Explorer over there.

Until now, Outlook has stood its ground as one of the better email clients when it comes to rendering HTML. Sure, there wasn’t perfect parity between Outlook and Internet Explorer, but it was close enough to make do. However, with the switch to the Word rendering engine Outlook has taken a leap back into the dark ages, and now ranks somewhere alongside Lotus Notes and Eudora in terms of its rendering capabilities.

Here are a few of the significant HTML and CSS goodies you’re going to have to kiss goodbye:

• Background images
  Want a background image on that table cell or div? Forget about it friend, you have to make do with solid colors from now on.
• Floats
  Just when HTML email designers were tentatively proclaiming that CSS layouts were achievable, Microsoft have decided to rain on our parade.
• Flash
  Your recipients are just going to see a “red x” where the Flash movie would have been.

And that’s just the tip of the iceberg – you can see a complete list of the missing HTML/CSS elements, properties and attributes on the MSDN site.

None of these limitations is going to make the task of designing HTML emails impossible, but they will ensure that no advances are made in this field for a good number of years. Remember, it’s been four years since the last version of Outlook was released, so I’m going to guess it’ll be at least six years before Outlook 2007 drops off the edge of the map.

Microsoft are claiming that enhanced security is behind the decision, which seems odd considering how they keep harping on about how secure Internet Explorer 7 is compared to its predecessor. And as usual it’s the web designers – and consumers – who get shafted. Hopefully when Microsoft’s customer base realize how crappy their HTML newsletters now look, they will start consider alternative email clients such as Thunderbird. Maybe then Microsoft will realize how shortsighted they have been.

Further reading

Broken HTML/CSS Rendering in Outlook 2007

Joe Hardy has an excellent gripe about the situation, and details some of the specific problems you might encounter when designing HTML emails for Outlook 2007.

Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007

Straight from the horse’s mouth.

To CSS or not to CSS?

CSS support in email clients varies widely. While most modern email clients have reasonable support for CSS, web-based email clients have an annoying habit of stripping stylesheets from between the <head></head> tags of your HTML document. They do this to stop your CSS styles overriding the styles of their own website – remember, your newsletter is being loaded into a parent webpage. Luckily you can get around this restriction by placing your stylesheet between the <body></body> tags of your document. This may be an unorthodox solution, but it will ensure your styles remains untouched. Unfortunately Google’s Gmail is not so easy to fool.

CSS support in Gmail is appalling. I mean, really, really bad. Gmail will not only strip styleheets from the <head> of your document, it will strip them from the <body> too. In other words, your HTML document will appear totally unstyled. And here’s the kicker: The only way to feed CSS styles to Google is to apply them inline, as in <p style="color: #000000; margin-bottom: 20px">. It makes me feel compromised and dirty just thinking about it.

Currently Gmail only has about 5% of the web-based email client market, and its users are no doubt accustomed to their HTML emails looking like a dog’s breakfast. You may decide you can afford to let them suffer. Myself, I suck up my pride and apply the styles inline. I know that some of my clients have Gmail accounts, and I don’t want the job of explaining why their HTML newsletter looks like it was designed in Word. Here’s hoping Google get their act together sometime soon.

Where page layout is concerned, I’d suggest you forgo CSS in favour of tables – almost everything I have read on the topic has agreed that tables are an unavoidable reality of HMTL newsletter design. In case you needed convincing consider the following: No web-based email client supports the position property, Gmail doesn’t support the float property, and neither does Lotus Notes which has a 9% market share.

The idea of using tables for presentational layout may be anathema to the standards aware web designer, but it ain’t as bad as it sounds. In the context of an email newsletter, a table-based layout won’t cause any of the long-term damage it might on a full-scale website. An email newsletter only has one page, which is never going to be updated or modified again, so an inflexible table-based layout won’t actually create any headaches down the track.

The curse of image blocking

A recent development in the world of email clients is phenomenon of image blocking. To help combat spam, around 50% of email clients now block images that are embedded in email messages. The logic behind this is that spammers often embed a 1×1 pixel transparent gif in the emails they send, to track whether an email has been opened. An increasing percentage of spammers are also using images in the body of their emails. Unfortunately, legitimate email marketers also use both of these techniques, and are punished along with the spammers.

The effect of image blocking on the appearance of your HTML email can be dramatic. It is imperative to know how your newsletter will look with images turned off, because that’s how a big chunk of your subscribers are going to see it. You can easily turn a web page’s images off in Firefox using the awesome Web Developer’s Extension.

Below is an example of how one newletter I subscribe to looks both with and without images enabled, to give you an idea of the impact it makes on visual design.

With images blocked:

… and with images enabled:

So what do do about the image blocking problem? There are a few strategies we can employ when designing an HTML newsletter:

• Use text instead of images
  There’s no need to forgo images altogether, just make sure that your newsletter is still easy to read when the images are turned off. Providing meaningful alt tags for images is a good place to start, but more important is to use text to convey important information rather than images. In the Icon Buffet example I showed above, the email may not look as pretty with images disabled, but the content remains just as accessible.
• Get Whitelisted
  Most email clients will not block images from a sender who is in the recipient’s address book. Encourage your subscribers to add you to their address book.
• Provide a link to a web version of your newsletter
  Place a text-based link at the very top of your email that launches a web version of the newsletter in the subscriber’s web browser. Text for the link should read something like: “Having difficulty viewing the images in this email? Read it in your web browser”.
• Attach images to the message
  If an image is embedded directly in an email as an attachment, rather than hosted on a remote web server, it won’t be blocked. If you are sending a small campaign from your own computer, this is fairly simple to achieve. I understand there are also some professional email marketing services which allow this too. But be warned: some ISPs filter emails with embedded images, as it is a popular technique with spammers.

Designing for the preview pane

Most desktop email clients feature a ‘preview pane’, allowing the recipient to view a preview of a message before deciding whether to open it. When the next generation of web-based email clients launch, they will feature preview panes too. This impacts on the way we design HTML newsletters, since we need to ensure the message still looks good at a glance in the preview pane, and doesn’t require horizontal scrolling. Keep your layout width between 500px and 600px and you’ll be fine, and of course put the most important content and the top of your email so it’s visible without scrolling vertically.

Here is an example of how the preview pane looks in the Mozilla Thunderbird email client:

Sending your newsletter

I’ve had a few clients who got nervous about the idea of using a third party company to send their email newsletters. In the past they had sent emails themselves from Outlook, and didn’t see any reason to change just because they now had a professionally designed newsletter. My advice: avoid this situation at all costs! Before you know it your client will be taking your beautiful newsletter template and attempting to edit it themselves in Outlook, butchering your layout – and your reputation – in the process. Add to this the fact that Outlook will magically turn your clean HTML markup into something resembling a spaghetti bolognaise, and you can see why it’s just a plain bad idea!

Fortunately their are some very reasonably priced options available for sending email campaigns on a client’s behalf, preserving the integrity of your design as well as offering a lot of powerful features you wouldn’t have otherwise. A friend recommended Campaign Monitor to me some time back, and I’ve now used them to send several client campaigns. Their prices are very attractive ($5 per campaign + 1c per email), and they offer a comprehensive client reporting system as well as great subscription list management. You can sign up for free and send small test campaigns to see if their service is right for you – I reckon you’ll be hooked after you give it a whirl.

Of course whichever way you choose to send your HTML emails, make sure that before you click the ’send’ button for the final time that you test, test and test again! Ensure you have final signoff from your client on every aspect of the layout and text copy. Send a small test campaign and preview the email in as many email clients as you can get your hands on. Here are a few to consider: Outlook, Eudora, Thunderbird, Mac Mail, Entourage, Hotmail, Gmail, Yahoo. You only get one chance, so make sure you get it right.

Further reading

HTML Emails – Taming The Beast

A great overview of the pitfalls you may encounter when you embark on your first HTML email design.

A Guide to CSS Support in Email

An extremely detailed checklist of CSS support in all the popular web-based and desktop email clients.

20 HTML Email Tips: Ignore at Your Own Risk

A must-read article covering design, usability and functionality issues

The image gallery was controlled by a Javascript which swapped the src parameter of a placeholder img tag each time the user selected a new image.

In my HTML markup I had a basic image tag with an ID applied to it:

<img id="placeholderimage" alt="" />

When the user selected a new image (by clicking ‘next’ or ‘prev’ in my image gallery navigation), a javascript was triggered to load a jpeg into the placeholder:

document.getElementById('placeholderimage').src = "mynewpic.jpg";

The problem with this method is that while the new image loads into the placeholder, the old image remains on the page. To the user it appears as if nothing is happening. The solution is to hide the image while it loads, and show the user some sort of load indicator while they wait. When the image has completed loading, reveal it again and hide the load indicator.

The specifics of hiding/revealing the load indicator are beyond the scope of this article, so I won’t bore you with them here. Instead I’ll demonstrate the method by which I hid and revealed the image, as that is what caused problems in Safari.

To hide the image, I used javascript to apply the CSS style display:none before loading the new jpeg. I also created an onload event handler for my image, to detect when it had finished loading. Inside my onload function I revealed the image again:

document.getElementById('placeholderimage').onload=function(){
        document.getElementById('placeholderimage').style.display = "block";
};
document.getElementById('placeholderimage').style.display = "none";
document.getElementById('placeholderimage').src = "mynewpic.jpg";

Easy peasy. The image is removed from the document flow when it starts to load, and returned when it finishes.

Everything seemed to be rocking nicely, until I fired up the site Safari 1.2. The image was hiding as expected, but my onload function was never evoked. After some head scratching I traced the problem to my use of display:block when hiding the image. I think Safari’s logic is that because the image is no longer part of the document flow, there is no point bothering to load it. Unlike other browsers, Safari never initiated the image load, and that’s why the onload never fired.

Armed with this new knowledge, we have a couple of “Safari friendly” options at our displosal:

• Use visibility not display

  If we use visibility = "hidden"; instead of display = "none"; to hide the image, everything works fine. The problem with using visibility is that the image is not removed from the document flow, meaning a gap is left on the page where the image used to be. Depending on the layout of your image gallery that may not be an issue for you – it may in fact be desirable. If it is an issue, you can set the height of the image (or it’s containing element if there is one) to zero, then use the onload handler to reset it to it’s correct height. Fiddly, but it works.

• Move the image outside the viewport

  If your image has the CSS property position:absolute, then you should be able to move it off screen by setting either it’s top or left property to a suitable low value, for example: left: -1000em; That ought to place the image off screen out of sight.

There may be other alternatives, and you can choose the one that suits you best. The important thing to remember is don’t use display:block to hide images while you swap their image source, or risk the wrath of Safari users!

For anyone interested to see the final implementation of my image gallery, here it is.