Thinking » Tags » CSS
As designers get used to all the new whizz bang inherit in HTML5 and CSS3, every now and then we get pulled back into the world of basic HTML rendering a là 1993 when we have to design e-newsletters for desktop and web-based Mail clients.
I recently had to create some templates for Constant Contact and I thought, “Hey, this should be easy. Can’t do anything tricky, so, keep the design simple, use a tried-and-true table for the layout, and viola, beautiful emails”. While you can’t do anything tricky, it’s true, there is so much more to consider, and it’s all pretty annoying if you are used to designing for the web. I enjoy designing for IE6 slightly better than designing email templates.
With that frustration in mind, here are some tips I ran across that might be useful for you, but will be very useful for me as I know I will forget them all just in time to design a new set of templates:
Design Specifically – Everything needs a class
The most annoying aspect of Constant Contact for a web designer who liked their code to be clean and nested is the fact that IDs are NOT supported, and neither are styles on HTML elements. So, the CSS selector body p is a no-no. Not even a rule that uses an explicit h1. Instead, you must define a .header1 class and apply it to an h1, like this: <h1 class="header1">.
Ridiculous? Maybe… but here’s why. When Constant Contact assembles your email, it takes all these rules and spells them out explicitly right in the element. So while you may define a normal style, it uses it as a reference and spits out an inline style tag on the element itself. So this:
[code lang="html" light="true" wraplines="true"]
.header1 { font-weight: bold; font-size: 20px; color: #333333; } <h1 class="header1">A Sample Header</h1>[/code]
Becomes:
[code lang="html" light="true" wraplines="true"]
<h1 size="20" color="#333333" style="font-weight: bold; font-size: 20px; color: #333333;">A Sample Header</h1>[/code]
It does this so it can cover the widest array of email clients out there. And it would be maddening for us to try and code this way with all those inline styles. So while the idea of using a stylesheet is like the web, the way Constant Contact uses the stylesheet is not like the web at all.
Design like it’s 1993
We all know KISS, but when I say simple, I mean REAL simple… 1993, beginnings-of-the-internet simple. Take the <center> tag, for example. The good ole margin: 0 auto; won’t work consistently enough, so break out the dusty <center> tag instead.
Use tables for layout. I know, I know, that’s SO 1993, but I’m serious… trying to consistently float divs and clear floats will drive you mad.
Also, forget bit-saving CSS shorthand. You’re better off using the full six-character hex values for colors when you normally might use three. Four values for padding and margin seems to be well supported, but use the long-form tags for font-size, font-weight, font-family, and background properties. Actually, forget background images all together. Many email clients won’t load them.
When using images, style the container like its text
This one may not be very intuitive, but let me explain. I’ve got an image, and it’s important – it’s the logo. I know some email clients won’t load the image by default (looking at you, Gmail), so when the image doesn’t load, I want the contents of the alt tag to display instead, and I want it to look good.
To do this, I simply made sure the container that the image is placed inside has some fallback styles for text. So while the alt text disappears when the image loads, if the user never loads the image, it still looks nice and we don’t lose important information, like the name of the company. Here’s what I’m talking about:
Before images load...
With images loaded.
Use Anchor (Jump) links Carefully
This one particularly bugged me, and took a little time to figure out. The client wanted a Table of Contents with simple anchor links to make the email jump down to the proper element. I knew that support for hrefs that jump down to an element with an ID would be spotty, but a simple <a name="anchor"> would work, right?
Silly me, what was I thinking?
Besides the fact that even these basic elements have spotty support (see this article from Campaign Monitor), there is also a problem of styling and the way Constant Contact handles empty HTML elements.
In order to appease the greatest number of email clients, my code for anchors links was <a name="anchorname" id="anchorname"></a>. But there was a simple problem with that. Since it was empty, Constant Contact turned it into a self-closing xHTML element, which looks like this in the source of the email: <a name="anchorname" id="anchorname" />. The problem is, most email clients won’t recognize an anchor tag that self-closes, so my email had open anchors everywhere, which turned my text default link blue.
The solution is god-awful, and I would never allow my web pages to look like this, but this is what I had to do for it to work and look good. I had to add a style class to handle these links, because even though there is no HREF declaration, email clients will still treat it like a link and turn it default link blue. :
[code lang="html" light="true" wraplines="true"]
<h3 class="header3"><a name="anchorname" id="anchorname" class="anchor">Headline Text</a></h3>
[/code]
Send us Your Tricks!
Designing emails is frustrating enough… and this list is by no means exhaustive. What issues have you encountered? Send them over here and we’ll keep them compiled for you!
In Conclusion
I hope you never have to design email templates, because they really can be frustrating. All the efficiencies you’ve learned while designing for the web get thrown out the window. Still, email is an effective (and cost effective) form of communication, so it won’t go away. It can only get easier as older mail browsers are slowly phased out, but the fight to eradicate IE6 is nothing compared to the fight to eradicate Outlook (Outlook has no support for simple styles like padding and float).
In short, stay sane, stay calm, and use Google to help you figure out the baffling problems of designing email templates. Keep the design simple and the message short.
And good luck… you’ll need it.
It is not often that web designers have to accommodate browsers that are considered “best of breed”. Maybe we are snobby when most of us design for Safari or Firefox and then “fix” things in other browsers, but, everyone has their preferred way of working. Internet Explorer is usually stricter in its interpretations of CSS, which makes some use it as a standard and other wince , but I digress…
So it was with extra frustration that I had to investigate a rendering bug in Safari / Webkit. Granted, it was happening only on an older version, Safari 4, and Safari 5 has been out for more than a few months now. But still, when you think Safari or Firefox are better browsers, it’s a wake-up-call to realize that like any browser, they have funny bugs and issues.
Endeca is a search and business intelligence company whose focus is business on the web. When they wanted a new blog that would focus on trends and insights for eBusiness, the team at Oomph decided it was time to use CSS3′s @media declarations for responsive template designs to optimize the site for multiple mobile and desktop devices.
The result was a super flexible theme, built on WordPress, that scales according to the user’s device size. One set of templates displays content in a few different ways, optimized for the iPhone, Android, iPad and desktop monitors of all sizes. Visit the site, grab the window corner to resize it, and watch what happens. Just one catch: current versions of Internet Explorer don’t yet support CSS3 (version 9, which is right around the corner, does add support).
For the developers out there, read on for a quick run down of what we did and how it works.
On January 11th, a microsite for Rhode Island Hospital hit the web. The content of the site addresses recent news and concerns about patient safety at the hospital and is meant to deliver the latest news and structural enhancements the hospital is undertaking to address and improve patient safety and quality care.
The design seems relatively straightforward until you learn that it was mocked up, coded and tested within five days. One Friday we were given the brief, and the following Friday we were delivering four coded templates, ready for content.
Last month a momentous site launch occurred at the Oomph headquarters. Jake was able to finally throw the switch and make the new Rhode Island Green Building Council Virtual Green Marketplace live. It was momentous for a few reasons, the first of which is of course the fact that this represents the first major comprehensive listing of LEED™-certified projects and “green” resources in the state.
Though the RIGBC site was developed on the WordPress platform, the first thing you may notice is that is does not have the typical “look” of a WordPress site. Since the site was designed and mapped out first, the CMS platform was chosen after the storyboards were developed. This allowed Oomph to choose the right platform for the job after the details of how the client wanted everything to work were mapped out. The site was developed from scratch, so we were able to make it look anyway the client wanted.
Ask any front end web developer to describe common challenges involved in converting (or “cutting”) a design. Ask a designer who’s savvy about front end web technology what the biggest creative limitation of the web “canvas” is. In both instances, you’d likely hear an earful about fonts.
For the front end web developer, it’s all about taking someone else’s creative – often designed on a highly controlled and extremely flexible canvas like Adobe Photoshop – and implementing it in the much less controlled and much less flexible world of HTML/CSS/JavaScript. Sometimes, a design that look great as a static image or storyboard just doesn’t translate well into web code, especially when not-so-design-sophisticated clients have to maintain the content and some of the imagery.
Fonts have long been a classic example. A storyboard designer can use any font they have installed on their own computer to make a beautiful design, but hacks aside, web browsers have only been able to render text with fonts installed on the visitors’ computers. Since there are only a handful of fonts that are more or less guaranteed to be on all modern computers (think Arial and Times New Roman), websites have been limited to a handful of uninteresting choices.
UPDATE: Paul Thurrott, a Windows journalist, has featured some commentary on our post over at his Winsupersite. Check out his post, and the great discussion below it! Thanks for the input, Paul!
Internet Explorer 8 is out, and a lot of people – technically sophisticated and otherwise – are wondering what, if anything, this means for the web. As professional web developers, our view is that while Internet Explorer 8 is an incremental improvement over its predecessor, we’re mostly disappointed by its lack of progress.
Having read a variety of takes on IE8, we were inspired to write this article for two audiences. First, there’s little in the way of concrete examples and clear explanations for a large swatch of the business technology decision makers (that many of our clients represent) who are often savvy about technology, but look to organizations like us for a deeper understanding of the strategic, cost, and technical significance. Second, reading the comments on tech savvy websites like Neowin, Digg, and the Winsupersite have me concerned that there’s a growing and false notion that IE8 is just great, and its rendering problems are the result of web developers writing non-standard code optimized for IE7.
To understand why IE8 is a legitimate disappointment, we need to start by providing background on how different browsers impact web development, both from a cost and design standpoint. If you think you already have a handle on this, you can skip ahead to our 3 straightforward examples of IE8 disappointments.