• The original typeface for Safari and Firefox 3.5
• A WOFF font for Firefox 3.6+
• An SVG font for Opera, Chrome, and iPhone
• An EOT font for Internet Explorer
• A sample HTML page
• A sample CSS stylesheet

The generator also features options to reduce file size by subsetting the font, cleanup font outlines, and auto-hint glyphs to improve rendering.

Sweet!

The trouble is that digital fonts have no provision for DRM, and pirating a copy of an embedded web font is a trivial exercise for anyone with the mind to do so. That’s obviously not a prospect type foundries are too keen on, and consequently no major foundry offers a licensing option for embedding their fonts in a web page. If you link to a commercial font from your CSS stylesheet the chances are that you are breaking your license agreement. Even the number of free fonts with an EULA that condones @font-face embedding is pitifully small.

That’s where Typekit comes into the picture. Typekit is a new font delivery service devised by Jeffrey Veen that promises to take the pain out of licensing fonts for web embedding. In their own words:

We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.

Here’s how it works:

• Typekit strike up agreements with type foundries allowing fonts to be licensed for CSS linking.
• Web designers subscribe to Typekit, and pay a monthly fee to embed typefaces on their websites using an @font-face declaration.
• Would-be font pirates are deterred from stealing embedded Typekit’s fonts by security measures including: allowing only authorised domains to link to their fonts; source code obfuscation; and splitting fonts into multiple files.

Problem solved, right? Well, perhaps.

Typekit’s font-as-a-service model navigates a clever path through the legal minefield of web font licensing, but I am not convinced that it is a perfect solution. In particular there are two aspects of Typekit’s approach that strike me as problematic: the fact that their pricing model is based around renting fonts rather than owning them, and the need to rely on remote servers for the delivery of fonts.

Renting vs buying

Because Typekit is still in beta details of its pricing are sketchy, but it is clear that customers will pay a monthly or annual subscription fee to access Typekit’s font library. This pricing model is significantly different to the traditional one-off payment required to license fonts for offline applications.

Will website owners be prepared to continue paying for a font month after month, year after year? Over time Typekit subscription fees could conceivably exceed the cost of a standard font license, despite the fact that Typekit’s fonts cannot be reused in any other medium, or potentially even on another website. And if you ever cancel your Typekit subscription, the fonts vanish into thin air. This is a radical departure from the current font licensing model, which grants customers the right to perpetually reuse any fonts they purchase.

Purchasing fonts twice

In addition to the fact that font subscription models require designers to pay for fonts they can’t reuse, in most cases it will also be necessary to purchase a regular installable version of each typeface.

To produce mockups and work on a production version of a website, a web designer needs to work with the same typefaces that will feature in the final live site. Typekit only offer web embedding of fonts, so to install a typeface on their local computer a web designer would have to purchase a separate font from another vendor. It’s not going to cut the mustard to produce mockups set in Arial and tell the client to “imagine that the headings are actually Avant Garde”!

When you also consider that many websites have multiple domain aliases (mysite.com, mysite.com.au, etc), and Typekit uses a per-domain pricing model, it is clear that the potential exists to pay many times over for the same font.

Network reliability

Another potential problem with Typekit is network downtime.

I can’t imagine many designers would trust their CSS files to a remote delivery network, and I think we need to accord fonts a similar importance. If major players like Google and Amazon suffer network interruption from time to time, then it is reasonable to assume that Typekit will too.

Admittedly, occasional network outages may not be a deal breaker, what happens if Typekit goes out of business, or a foundry retracts the right for Typekit to distribute their fonts? In either of these scenarios it seems probable that Typekit subscribers would have the fonts rudely stripped from their websites. In a best case scenario subscribers could turn to a Typekit competitor such as Fontdeck to revive their font links, but what if no competitor offered the same typefaces? The design of countless websites could be irrevocably ruined due to their dependence on remotely hosted fonts.

The future of font embedding

Despite the reservations I have outlined above, I have to agree with Andy Clarke when he predicts that Typekit will change everything.

By coming up with a practical answer to the problem of @font-face licensing, Typekit has paved the way for alternative font embedding approaches. Clearleft and OmniTI have joined forces to create Fontdeck, and at least one foundry, Typotheque, has a web font service under development.

Soon there will be a number of services vying with Typekit to win the hearts (and wallets) of web designers, however I suspect the deciding vote will ultimately be cast by large font foundries such as Linotype and Adobe.

The type industry’s major players will need to decide where they stand on the issue of font embedding, or they risk being left behind while smaller type foundries reap the benefits of web font licensing. If they follow the lead of their counterparts in the music industry it might be years before our @font-face woes are sorted out. On the other hand they might choose to take the bull the horns and launch their own font hosting services to compete with Typekit.

Whatever the response of large type foundries and vendors turns out to be, it will very likely determine the future of typography on the web. Hopefully we end up with a solution that is fair to web designers, website owners and font foundries alike.

Further reading

Introducing Typekit

Jeffrey Veen announces the arrival of Typekit, and explains the basics of how the service will work.

Ubiquitous web font embedding just got a step closer

John Allsopp argues the case for more liberal font licensing. Recommended reading.

First impressions of Typekit

A step-by-step tour of the Typekit beta.

On Typekit

David Yeiser shares some of my reservations about Typekit.

The Font-as-Service

Jay Elliot Stocks gives an overview of Typekit and its competitors.

Testing Typotheque @font-face embedding

Andy Clarke takes Typotheque’s new web license for a spin. It is interesting to note that Typotheque requires a one-off payment rather than a subscription like Typekit.

But today I came across Scaffold, a CSS framework that made me rethink my position.

Scaffold differs from traditional static CSS frameworks in that it runs on a web server, and acts as a compiler. Scaffold extends the power and functionality of CSS by parsing each of your CSS files using PHP and generating browser-readable stylesheets on-the-fly. Some practical benefits of this approach are:

• Automatically cache and compress CSS files
• Declare constants in your CSS file and reuse them later in the stylesheet
• Call mixins (functions) from your CSS selectors
• Evaluate portions of your CSS as PHP
• Nest CSS selectors

Ruby users will be familiar with many of these features from Compass and Sass, but Scaffold brings server-side CSS to the Apache/PHP user base.

Extending scaffold using plugins

Scaffold’s feature set can be extended using plugins. In addition to bundled plugins for compression, image replacement and generating human readable output, there are plugins for targeting specific browsers, creating grid layouts, and extending selectors (true OO CSS!).

How it works

Scaffold works by routing your CSS files though its PHP library, parsing your Scaffold code, and generating a standard CSS styleheet which is returned to the browser. Installation is a matter of dropping scaffold into your CSS directory, modifying a few settings in a PHP config file, and setting Apache folder permissions for the directories that Scaffold needs to write to.

You have two options for passing files to Scaffold: route all CSS requests to Scaffold via .htacess, or change the CSS links in your HTML so that they point to Scaffold.

<link href="scaffold/index.php?request=screen.css" />

Scaffold is definitely a CSS framework I could learn to love, and I’m really looking forward to using it in a project. Compared to the current batch of static CSS frameworks Scaffold looks like a big step forward.

Let’s say we want to display an image with a title aligned to its top right corner, and a caption aligned to its bottom right corner:

Here is the CSS:

.portfolioImg {
    float:left;
    margin-right: 20px;
}
.imgDetails {
    position: relative;
    float:left;
    height: 280px;
    width: 150px;
    }
    .imgDetails p {
        position: absolute;
        bottom: 0;
        }

Here is the markup:

<img class="portfolioImg" src="monster.jpg" width="280" height="280" alt="Knitted monster" />
<div class="imgDetails">
    <h2>Image title</h2>
    <p>This is the image caption. It is aligned to the bottom of its containing element.</p>
</div>

The trick is to set the position of the container to relative, and the position the of the child element to absolute. Then set the child’s bottom property to 0.

Photo credit

The photo of the cute knitted critter in my example is by Tamie Snow. You can learn more about her wonderful knitted creations at Roxycraft.

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>

Download

Download Photoshop CS2 file

How to use it

Here is some simple CSS styling you can use to turn an ordinary link into a spiffy looking file download button.

The HTML:

<p class="fileDownload">
    <a href="myfile.pdf">Download Annual Report (PDF 120Kb)</a>
</p>

The CSS:

.fileDownload {
    background: transparent url(file_icon.gif) no-repeat left top;
    display: block;
    height: 35px;
    padding-left: 36px;
}

The final result:

Download Annual Report (PDF 120Kb)

Posts are divided by category, such as ‘Float’, ‘Margin’, ‘Safari’ and ‘Color’, and can be rated by community members to indicate how useful solutions prove to be. CSS Advisor is still in beta and remains fairly bare at this stage (90 posts), but hopefully the forum will continue to grow over the coming months as word gets around.

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.