ardes
So Microsoft have distributed the next public release of Internet Explorer 8. If you’re using XP (and who among you, honestly, is using Vista?), you can get it here.
Here’s an interesting note in the “known bug” list: looking at the markup within an iframe tag is impossible if the first item within is a comment. Ohforchristssakeareyouserious.
If you’re using Mac OS X and you’re a developer and you’re too busy working to think about backing up your work, then Time Machine is fantastic & a lifesaver. Time Machine will automatically back up your work on an hourly basis. Coupled with a Time Capsule—which provides both the storage for those backups and your wireless connection—backing up is seamless, which is as it should be: if it isn’t seamless, you’re not going to back up nearly as often as you should.
However, Time Machine is not without its faults. I found it frustrating to set up initially, as I was setting up individual accounts (with passwords) & the setup for this is not clearly laid out. Worse, however, is that you can’t set up default rules—like ignore any directory named logs (those developing in Rails will know the files in logs can get huge), although you can set directories (or files) to be ignored manually.
Worst is the lack of any idea of what Time Machine is backing up. When you’re a developer, this can be very frustrating, as periodically you’ll find that you’re suddenly backing up gigabytes of data without knowing why. This is bad: when Time Machine runs out of space, it removes the oldest backups, so you can’t go “back in time” as far as you may need to. For instance, my last backup is 4 October when it should be something back in June, when I first bought the Time Capsule. Something was eating up space.
You could adopt a Zen attitude to this: let it do its thing, accept this state of affairs & doubtless you’ll be happier—until your Time Capsule is filled, that is. Or, you could be obsessive-compulsive & make yourself miserable trying to figure out wtf is going on. TimeDog helps you see something of what’s been backed up, but I found it unhelpful as it wasn’t letting me know about the latest backups—in my case at least, it only appears to give you information about the initial backup. Well, that’s not helpful.
Last night, however, the right chain of events occurred that provided the solution—for web developers, at least. I was performing a MySQL sync for one of my clients—in this instance, I also sync the database locally so I can check my work against the client’s actual data. Time Machine started up just after I started syncing locally. At first it was backing up about 2.5MB. Suddenly, however, it was backing up over 2GB worth of files. Strange, I thought—I had excluded the db folder on the Rails project, so the synced YML files shouldn’t be backing up.
And then it hit me: Time Machine was backing up the actual updated MySQL databases. Obvious, really, when you think about it. For Mac developers, your MySQL databases will be in one of two places:
/var/db/mysql;/opt/local/var/db/mysql.All you have to do to remove these from backups is to go to Time Machine preferences, click “Options…” & exclude the above directories.
You may want to prune more selectively, however: for me, the db sync only really affects one particular client. You can go into the mysql directory & merely prune out the database that’s filling up your Time Machine. Please note that this database won’t be backed up, however—you may want to back it up manually at specific intervals.
In the past couple of months, two authors whom I admire have renewed interest in Dean Edwards’ confusingly-named IE7 script—a Javascript hack that makes Internet Explorer version 6 behave more like a standards-conscious browser.
The very title of Eric Meyer’s article—“Javascript will save us all”—suggest that we’re about to enter a golden age in support for the seven-year-old browser. And Jeremy Keith has recently advised people how to gauge when to use the IE7 script.
Well, I don’t know about you, but to me, this is more than music to my ears, it’s the equivalent of Bach being played on a glass harmonica right next to a chocolate fountain. But years of struggling with IE6 have hardened my defences. Since using Meyer’s CSS zero reset I’ve had great results with IE6—but only from the beginning of a site design I hasten to add. As I’ve written earlier the reset does little to fix a pre-existing design.
Dean’s script has popped up now & again over the years to tempt me again & again with its promises. But it’s nowhere near as well-known as you’d expect for something that gets such high praise from some very astute authors. Why is that?
Well, it might be because it doesn’t really do what you hope. It’s certainly nothing like a magic bullet. In fact, I’d recommend that you stay away from it. Why? Because you’ll have to go through the hard work of declaring a separate stylesheet for IE6 anyway: adding another script to the mix just adds more to the confusion of figuring out why something doesn’t work.
Both Edwards’ script and Keith’s recent article popped into my head because recently we’ve been working on the site of one of our favourite clients. In the course of making the site more amenable to search engine optimisation, it became clear that we should revisit the CSS of this, the last site we developed without the CSS reset.
The DD site as planned, in a standards-compliant browser
The DD site, as seen in IE6, based upon particularised CSS tweaks
The DD site, as seen in IE6 with Dean Edwards’ IE7 script
Now, it might seem like I’m cheating in the above examples: I removed the painstakingly-tweaked IE6 CSS when I introduced Edwards’s script. But I’m not. If I were to follow Meyer’s & Keith’s advice & used the IE7 script as a basis for my IE6-oriented work, I’d have a hell of a lot more tweaking to do, plus I’d have to cope with the rigmarole involved in dealing with someone else’s script.
So, take some advice: if something looks like it’ll magically solve all the problems that have consumed years of painful work, don’t bet your reputation, or your schedule on it.
Search Engine Optimsiation (“SEO” for short) is important for web developers & their clients alike. It’s often described as a “black art” because no one outside of the search engine companies know exactly how search engines work (I mean, c’mon, it’s a trade secret). Companies like Google & Yahoo give pointers to help web developers do right by their clients, and in the right way (“best practice”), but they’re—necessarily—incomplete. In any event, we all want to perform well in search query results.
The following is a report from a couple of events sponsored by Business Link that I attended with one of our clients, Rick from specialist door manufacturer Distinctive Doors. It seems fair to present this stuff here, given that the events were a) free & b) open to the public.
The events were conducted by Mark Kelly of Click Appeal & Jon Colegate of Sunflower, respectively. Each session provided good information. We at Argument from Design knew much of it, but you’re just kidding yourself if you think you know it all. These talks quantified their claims in real terms & attendance at such events—like hanging—“concentrates the mind wonderfully”. Taken together, they presented a good overview of SEO. They preached “good practice”—which isn’t really a secret, but might as well be, given how little this is understood by the more general population.
Contents of this Report. Please note that I’ll be mostly going sequentially through the events, but I’ll periodically jump back & forth between the two, as the two were quite complementary. Also, I’ve peppered commentary throughout.
Note that you can tidily divide SEO stuff up between what the web developer, site owner & SEO marketer need to do, respectively; I haven’t followed that road here because there would be a lot of repetition. Marketing your site effectively & getting to the top of search results is a joint effort & this report has been organised to reflect this.
Mark Kelly presented “Turning your site into a customer magnet”. Designed as a “mini-session” on SEO, Mark emphasised the content of the site & how it was structured, all in terms of that cornerstone of SEO, keywords.
Whilst those inside web development may find it hard to believe, your average business owner often doesn’t really understand what keywords are, much less how to come up with useful ones (indeed, it’s another example of how web developers have to educate their clients in order to make that website successful). Keywords are the terms that punters use to find your website: they’re the words they enter into Google (or, if they’re feeling retro, Yahoo, Ask or Altavista) to find your products or services. If your site is well-structured (more on that below) and if you’ve chosen the right keywords, then potential customers will come to your site & you’re on the road to success. But how to come up with those all-important keywords? Where do you put keywords? How do you create the right mix of keywords for a given page? How do you quantify any of this? And what should you expect from your web developers? Read on.
To come up with keywords, Mark suggested WordTracker, which offers a chargeable service (they also offer a limited trial); Jon suggested Google Adwords’ free keyword tool. While we all appreciate free stuff, I suspect web dev professionals will want to at least take a look at WordTracker—whichever you prefer to use possibly depends upon their respective interfaces.
So why use a keyword tool instead of just figuring it out yourself? Because you may be wrong—very wrong—about what prospective clients search for. These tools help you understand the language your audience uses. They also give you an idea of how many people have searched for a given term—but just as importantly, they provide information about the volume of competition (in terms of advertising) for that given term & variations to try. Why would you want to try variations?
Mark gave a great example. It was put in terms of purchasing ads, but the exercise works equally well if you aren’t considering ad purchases. Let’s say you sell nice leather goods. If you put up an ad for “quality leather goods”, you’re going to get hammered by the amount of competition for the keyword: because many people will search for the term, you’re paying for lots of eyeballs to perhaps visit your site. And of those that do visit your site, only a fraction will stay—because you won’t have what they want.
A smarter way to go about the whole endeavour would be to increase the specificity about what you’re offering: i.e., put up an ad for “quality leather laptop cases”. Why? First of all, because the competition would be lower, and therefore cheaper, for the ad; but more specifically, you’re targeting something specific that someone might search for. Whilst fewer people will search for this second term, they’re more motivated to buy. And you can be even more specific: “yellow quality leather laptop cases”. It’ll be even cheaper to purchase the ad & your potential customer will have found what she wants that much more specifically. The motivation to purchase is that much higher. (Oh, and don’t forget a clear & visible “call to action” like “Buy Now!”).
(Incidentally, Mark argued for different landing pages for the different products, i.e., yellow laptop cases, green laptop cases, etc., the notion being that the visual connection with what the visitor searched for & then sees is very important. I’m a bit dubious about this, but web developers should consider the point in designing their sites. Jon made the point, I feel, better: don’t hide all your products or services behind a single page. Why? because you’re diluting your keyword density).
OK, so we know what a keyword is, we know about the value of the keywords we want to use, in volume in terms of queries & (if it’s relevant to you) ad revenue. So how do you use keywords effectively?
This is something that SEO specialists bang on about a lot; indeed, Jon did, too, but Mark did a better job with a a great example. First of all, he presented a paragraph of text (presumably from his own website); then he presented the same slide with the keywords highlighted. Here’s what he wrote:
It’s no secret: ecommerce continues to go from strength to strength. Many businesses benefit greatly from adding an ecommerce solution to their operations. The internet also offers many cost effective opportunities for starting a small business, ideas for new businesses & home business. 2007 was another fantastic year for online sales.
Many business owners now place e-business high on their business plan for 2008. Where to begin? How can you find out how to get the most out of your budget and make the right choices when planning and implementing your e-business and selecting such services as ecommerce hosting & shopping cart solutions?
Now here it is again, showing the keywords in italics, plus the number of daily queries for that term. By using the keywords discretely—and naturally—the page was able to cover some 2,037 daily search queries:
It’s no secret: ecommerce (284) continues to go from strength to strength. Many businesses benefit greatly from adding an ecommerce solution (49) to their operations. The internet also offers many cost effective opportunities for starting a small business (77), ideas for new businesses (40) & home business (570). 2007 was another fantastic year for online sales.
Many business owners now place e-business (91) high on their business plan (567) for 2008. Where to begin? How can you find out how to get the most out of your budget and make the right choices when planning and implementing your e-business and selecting such services as ecommerce hosting (140) & shopping cart (219) solutions?
I’ve read about the tactic—and it’s a completely legitimate tactic—but this was such a good, concrete example that I had to present it here. Now let’s not fool ourselves: the prose won’t win any awards. But those paragraphs read completely naturally. Compare that to all too many sites out there that use the same phrase (like “plasma tv” multiple times in a short sentence) & you can see that this was written for humans. Which, after all, is what you’re actually trying to reach, even though you have to pass through a mechanical filter.
Certainly this is something over which we as a business have been inconsistent, even unclear, with clients. We of course talk to them about keywords, but not in detail like this. Using a quantifiable approach like this is very valuable.
An aside now. Both Mark & Jon had to contend with some pretty random questions from the business owners attending these events. Many of the attendees genuinely had a hard time following a lot of this stuff (and why wouldn’t they? whilst important to their businesses, it’s not their sole concern) & both presenters had to struggle to keep on subject & to time. For us web developers, it’s another lesson in how we have to guide our clients, gently, in these topics. They’ll struggle thinking about all of this in general terms & will want to make it more concrete by talking—at length—about their own businesses.
More relevant to this part of the discussion, however: no matter whether the attendees were having trouble following this, they’re likely to write awful prose. Add to this the fact that most clients struggle to come up with their own content—it’s the single most common reason why web projects miss their deadlines—and perhaps you can see that having a copywriter in your stable is a priority. If you’re in South Yorkshire & you don’t know any, we can put you in touch with some copywriters.
OK, so we know that we’ve got to write natural-sounding prose. Where else should you place those keywords?
Title tag: and be sure to place it before the company name, so that the keywords appear in truncated search results;/leather/laptopcases/yellow/ is far better than /categories/2/products/6—this is a problem that Rails developers suffer from, perhaps all the more if you’re into RESTful URLs;Meta tags: both the keywords & description variants;h1, h2, etc.);Business owners with self-created sites, and many web developers as well (we’ve certainly been guilty of it) will often make a mistake and lose a big opportunity: they’ll put the company’s name in the h1 tag (and perhaps use more than one h1 tag, which is also bad). It’s the misguided notion that somehow you want to prioritise the company rather than the product or service being sold. Search engines value the ranking of the various heading levels appropriately, so use them well. Each page on your site should put the purpose of that page—defined in terms of your keywords—in an h1 tag & then use the following heading tags appropriately. As Jon said, the page should clearly express what it’s about; and those heading tags will help you structure the meaning of the page. Use wisely.
As an aside, this brings up the issue of relevance. The heading tags will help structure the meaning of the page; but search engines have greatly improved their ability to parse the relevance of terms to a page. If you’re struggling with your own site, trying to force your keywords into your document unnaturally, stop: a copywriter can help you. Just be sensible.
So that was the meat of Mark’s talk. Jon’s talk (“Taking Control of Search Engine Optimisation”) was more generally about SEO rather than simply a subset of keywords & content. You perhaps can see why I think Business Link should have offered these two events in close connection with one another, because together they were more than the clichéd “sum of their parts”.
Jon immediately started off with some critical figures: First, he concentrated upon Google because Google have about 90% of the UK search market. The first entry on a Google query result will derive about 50% of click-through traffic (“click-through” refers to visitors jumping from the search engine to a site that provides them with what they’re seeking). The second entry derives about 13% of click-through; and it trails off from there. So, um, the obvious point here is: try to get to number one. How to do that?
“Organic” query results derive from popular sites, good content, well-formed (X)HTML & accessible content—of all these points, the first two probably matter most, but the others help considerably. If BoingBoing, Slashdot or the BBC link to your site, that’s a big vote of confidence from very popular sites. You thought popularity contests ended in school? Wake up and smell the coffee!
Good content matters, too. People look for information; unless they’re looking for a very specific product, they’ve not come to your site just for the pleasure of a salesman’s pitch. They want helpful information. In fact, Mark spent some time in his talk discussing the fact that if you provide useful information (such as answering “What’s a DSLR?” or “How to choose a DSLR?”) you develop trust. I started reflecting that your average business owner’s conception of selling on the web squeezes out the whole importance of developing trust. No wonder many people find their sites don’t perform as they hoped.
And not just search engines, but people, too! This is related to using keywords effectively & writing good content, but again, this needs to be explicitly stated. If you don’t update your site with new content, search engines will reasonably assume it’s been abandoned. How many websites have you seen where the most recent item in “Latest News” is three years old?
Poorly-formed markup & poor accessibility affect your performance. If you use (X)HTML properly & don’t put your content behind a firewall made from Flash or Javascript, search engines will find it & evaluate that content more easily. Remember: searchbots cannot read Flash, cannot use Javascript & cannot view images. They are entirely dependant upon what you write; more specifically, what you write out in the open, so placing good content behind a login is a problem.
Now, practically speaking, accessible, well-formed markup may only shave off 20% of your site’s search problems; but that could make the difference between being #1 in those query results & being an also-ran. Why? Because most sites out there are still formed poorly.
Mark & Jon both emphasised a good navigation system, preferably one that uses your keywords. This seems like a no-brainer to me, but there are lots of sites created by graphic designers (who make beautiful stuff, but they’re not information designers) that prove this needs to be made explicit. Jon also recommended a sitemap. The need for this seems obviated by a good navigation system, but it’s something to consider.
Finally, be aware that good organic search results take time—and money. This makes sense, because if popular sites are going to link to you, you’re going to have to make a concentrated effort to attract their attention; developing good content doesn’t happen overnight, either. Keep all this in mind when your new client states “And we want the site to rank #1 on Google in a week”. I know you’ve been there.
This was interesting & Jon’s thoughts on this were compelling. Several attendees clearly thought that advertising was the way to reach the top of Google. Well, because it is: you pay to be one of the “sponsored links”. But that’s a fiscal arms race with your competitors. Jon thought it better for short-term goals, like presenting a new product to the marketplace. Your placement will rise & fall with that PPC that arms race; the groundwork of (say it with me), well-formed markup & compelling, accessible content—that is, your organic work—will matter much more for your long-term success.
That’s not to say PPC doesn’t work: it does. The point here is that your efforts should be concentrated upon your organic query results.
One of the first things that really hit me attending Jon’s event was his crystallisation of something I’ve been saying for a long time: web development and marketing are not the same thing. On the face of it, this seems like a totally obvious & non-controversial thing to claim: yet remember the client who’s said “And we also want the site to rank #1 on Google”? Clients will easily confuse the fact that we can develop marketing tools with the act of marketing itself. The two are different.
Web developers can provide a firm foundation upon which to build your optimised site; but you may well require marketing professionals to derive the full value of it. Not to bang on about it (OK, I’m banging on about it), this is something we often emphasise to new, and less experienced, clients. We provide good, solid code where the content-to-markup ratio is very favourable; we make the site accessible using progressive enhancement techniques; and we will work closely with you on the application flow so that the site works as you need it to. But it’s really up to the site’s owner to provide the compelling content & the marketing budget necessary to do really well organically.
OK, so we’ve already covered keywords (or key phrases, if you like), writing & updating good contentm removing barriers to search engines, clarifying the page’s purpose, what’s left?
Why, the bad stuff, of course! Again, this is a no-brainer. Avoid unnecessary redirects, which can suggest that you’re performing some sort of bait-and-switch. Definitely don’t try to hide text (say, white text on a white background or text in a one-pixel box set to visibility: hidden).
Most of this report has thus far covered what web developers & site owners can do for a site. The rest is more in the realm of marketing. And, as you’d expect, it’s hazier. Marketing people are more hesitant to divulge their secrets.
We’ve mentioned that SEO is, in part, a popularity contest: your page rank is affected in part by who links to you. What matters are the quantity, quality & relevance of those links. Why is this important?
This in part explains the increased importance of “social networking” sites like Digg, Magnolia, StumbleUpon, Youtube, Facebook & blogs—sites can become naturally linked as like finds like and the like, erm, like what they’ve found. And it makes sense from a psychological perspective: it rekindles the joy of serendipity, something written about, movingly, in The Long Tail.
From a corporate perspective, though, this is why SEO is partly a marketing issue. You’re unlikely to naturally become the next Will It Blend—you’ll have to use PR & other marketing tools to make your voice heard.
Remember: text is king. Text gives context & relevance. If we link to your site with an image, search engines only have our alt tag to provide any context. A textual link is, therefore, better. For instance, we might want to have the link text to our site state “Sheffield-based Rails developers”—“Argument from Design” doesn’t provide context (or, indeed, a judgement on the link), so the latter is less useful.
What does this mean? From a corporate standpoint, it may well mean that you want to develop a link policy, where you cite the types of things the link text should state. Be sensible, though: if you told me I could only link to you if I used the text “super awesome”, I’d certainly get Bolshie. And if you tried that with BoingBoing, you will most definitely get humiliated before a very large audience. Complying with your link policy is only a request that you can make, a courtesy that’s extended only if you’re reasonable about your terms.
Also, try to encourage links to pages other than your home page. This partly helps in terms of increasing relevance, but also helps search engines index your site & discover perhaps hidden elements to your sparkling personality.
Your average business owner will always discuss reciprocal linking with web developers as if it’s the golden key to riches. In our experience, they’ll link to other sites willy-nilly. They do this because some SEO person said it works. Well, it can work. But it rarely works. Why? What went wrong between the communication of a strategy & its implementation?
It’s almost certainly because of relevance. If a financial services site links to a windows cleaning site & a greetings card site, it doesn’t feel right, it seems unnatural. In fact, it feels like the online version of BNI—some small business networking agreement.
To my mind, a good way of developing a reciprocal links policy follows from providing good content: when you write something compelling & you link to someone you respect, and that person links back to you in the context of something he writes, that’s real reciprocal linking. A few months’ reading of Jon Gruber’s Daring Fireball will provide plenty of examples of this—although there can be more than a whiff of mutual regard (note how many linked articles reference Daring Fireball & you’ll see what I mean). It reminds me of Spy magazine’s old feature “Log Rolling in Our Time”. Then again: what’s the big deal? Jon Gruber & his linker are participating in a real conversation: they’re providing relevance & context to one another because it makes sense to do so.
Without going through a Bataan Death March of iffy content production, social network chummery & seemingly random site linking, what link building strategies should business site owners pursue?
Are do you notice anything about the marketing portion of this report? That it’s a bit thin on the ground & hand-wavy? I noticed this, too, as did several of the attendees. One asked whether there were “secrets” that SEO marketers employ that the punter cannot. Jon hesitated & said “Yes”. He didn’t elaborate.
And why would he? The attendee was in effect asking him to give away his business for free & Jon wanted to protect his business. Jon & Mark were both encouraging “good practice”—which aren’t per se secrets, but certainly are received as such by your average business owner. There are going to be several ways which SEO specialists will try to effect your ranking. But the question & Jon’s response raise something that’s both a question & a worry: what do SEO specialists do for you, exactly?
Note that Jon said Page Rank is valued because it’s difficult to game the system: not impossible. My concern would be that your SEO specialist should use acceptable techniques to help your site & this is something you should question closely. SEO specialists have a really poor reputation (at least among web developers) for being, well, weaselly. Let me be clear: Mark & Jon came across well. And I’m not saying that SEO marketers will put your site in some sort of link farm—they certainly don’t want their customers to be blacklisted from Google—but by employing SEO specialists you are perfectly within your rights to ask them what they plan to do for your site, without their having to divulge any secrets. I can make some very simple-minded guesses about some things: for example, they’re likely to find appropriate partners, PR sites & industry-specific blogs that could be successfully used to create real links. But that’s just the stuff anyone can easily conclude from what Jon outlined: what else might they do?
It’s going to be a question of their ethics & as we’ve mentioned, the SEO profession doesn’t have a great reputation. Of course, all this could mean is that some are poisoning the profession for everyone else. But have you ever come across an obviously automated blogs that simply collect data & barf out “content” for linking purposes? I think we can conclude where they come from. Again, question your SEO person very closely about what they plan for your site.
I promise to be brief (now? I promise now?!?). These events were about three hours long apiece, all told (including breaks) & if you cast your eye over what you’ve just read, you’ll see that they covered a hell of a lot of ground.
As I said at the beginning, attending an event like this concentrates your mind on the subject. During & after each event, Rick & I were filled with ideas to implement, both for his site and our own. I’m hoping that writing this stuff down, in one place, will help others concentrate upon it. After all, it deserves your concentration—if you won’t devote time to your site, your competitor will to hers; and anyway, why would you invest your money in the first place if you don’t want your site to prosper?
Well! We certainly haven’t updated in a long time. Happily, the reason is that we’ve been busy, in fact the busiest we’ve ever been.
I thought I’d go over one aspect of a site we developed, as the subject isn’t particularly well-covered on the web. The subject is font embedding, also known as web fonts, which has been around as a technique—although rarely ever implemented—since the original “browser wars” of the late 1990s. As this is a real-world example, I can provide information about font rendering, display & other bugs and finally tool usage.
First, let’s define what we’re talking about. If you search for “font embedding” or “web fonts”, you’ll get wildly differing instructions because people are talking about different things. For instance, many people will use these terms to explain how to access standard fonts on a computer via the font-family declaration in CSS. Some older pages may describe using font-face tags inline to change the usage of fonts—that is, to use Arial instead of Times New Roman for a passage of a page. Both of these techniques refer to the fonts installed on the end-user’s computer & as such pick from the list of likely fonts to use: Helvetica, Arial, Times New Roman, etc.
Neither of these is what we’re talking about, however. Back in 1998, in the CSS Level 2 recommendation, the W3C discussed font downloading as a technique to use fonts that the end-user doesn’t have installed. In this case, the browser downloads the font for use on the site in its cache—once you’ve browsed away from the page or site that uses font embedding, the font is no longer used & you cannot access it for use on your system. While the W3C discussed different formats that could be supported, Netscape & Internet Explorer opted for competitor formats that were, essentially, encrypted, PFR (TrueDoc Portable Font Resource) & EOT (Embedded OpenType), respectively. Because the font is, essentially, embedded, this is why I’ve decided to opt for the term “font embedding”.
Developers’ responses to this innovation was best described as muted. In a period where the two browsers were going hammer & tongs at each other & supporting wildly different tags & formats, developers had their hands full supporting far more basic things than font embedding. Font embedding withered on the vine, despite some attempts to revive it.
WebKit—the engine that drives Safari, among other browsers—listed font embedding as a new feature in October 2007. This has spurred re-interest in the use of font embedding, as Safari & Internet Explorer now support it.
Here endeth the history lesson.
So, back to us. We had a client who had a pre-existing website that was rendered entirely in images. Updating the site’s content was, obviously, a nightmare & moreover, search engines knew nothing about any given page’s content. They contracted us to make it editable. Accordingly, we developed a lightweight CMS for them to handle the content.
However, they also wanted us to use their typeface, based upon VAG Rounded Thin. What were the options? Hmmm. Hmmm. Hmmm.
It turns out that there are four options. They’re listed here from least desirable to most desirable (in this example):
font-family. We could display the font using the font-family CSS declaration & hope that the end-user had the font. This was deemed undesirable because of its unpredictability.And so we began our odyssey into the world of font embedding and undocumented bugs & features. Join us as I gather up the hair that fell from my scalp & attempt to glue it back on.
There are few pages on the web that give you much information about font embedding. Moreover, even though the idea’s been kicking around for a decade, because few have ever really tried to exploit it, the featured is often half-baked in implementation.
So, looking at Safari & Internet Explorer, we know that we can use TrueType fonts & EOT files, respectively. You declare font embedding in your CSS thus:
@font-face {
font-family: "VAG Rounded Thin";
font-style: normal;
font-weight: normal;
src: url('vag_rounded_thin.ttf');
}
That alone won’t work, however. You also have to declare where it’ll be used:
body { font: 1em "VAG Rounded Thin", "Trebuchet MS", sans-serif; }
And behold, in Safari, it works:
Font embedding sample seen in Safari 3.1.2
This doesn’t work in the most popular alternate browser, Firefox:
Font embedding sample seen in Firefox 3.0.1
This is why, in this case, we opted for Trebuchet as a fallback above in the body declaration. It’s similar enough to VAG Rounded Thin that the difference isn’t jarring. For your own work, I recommend that you look for the common font most similar to the one you want to embed. Also, because font metrics vary so dramatically from font to font be very careful in your CSS declarations. I strongly recommend using Eric Meyer’s “CSS Reset” to give yourself as solid a foundation as possible.
Incidentally, font embedding also doesn’t work in Opera:
Font embedding sample seen in Opera 9.5.2
Now for Internet Explorer. You have to use a tool to convert your TrueType font to the EOT format. Microsoft provide WEFT, a free tool for doing this. It’s Windows only & I guarantee that its interface will take you back to the days of Windows 3.11.
WEFT works, but there are caveats. It would ideally like to attach the embedding information directly to your pages. This is really problematic if you’re using a template-based system—which we were, as we developed the site using Ruby on Rails. What you have to do is tell WEFT to ignore your site & place the EOT file onto your hard drive.
Because its intention is to restrict unauthorised use, WEFT also wants to know what URLs are allowed to display the typeface. Happily, it supports multiple entries, so be sure to add the name of your machine. For example, I added http://localhost:3000, so I could preview my work before showing it to the client.
NB: be sure to add all the URLs you’ll require, otherwise embedding will fail in Internet Explorer:
Incorrect font embedding sample seen in Internet Explorer
Here it is working in Internet Explorer version 7:
Font embedding sample seen in Internet Explorer 7
And here it is, with the “L”looking like ass, in Internet Explorer 6:
Font embedding sample seen in Internet Explorer 6
So why does it look like ass? Read on.
Well, there are lots of things that I haven’t explained about font embedding. One of the things is that it doesn’t always work well. When we converted the typeface to EOT format, we discovered that, for some strange reason, it wouldn’t show typographically-correct glyphs (like “”, —, etc.) in Internet Explorer 6. However, we were initially provided with a free rip-off version of the original font. When we converted this to EOT, everything worked fine. Now why would this be?
Keep in mind that we’re now talking about different fonts. It turns out that font makers have the ability to declare embedding rights. It’s located in the fsType. It might be that when converting the font from TrueType to EOT, some of the characters of the font wouldn’t translate. This is guesswork & I might be entirely wrong.
Another problem, which I haven’t explained, is that accessing the boldface version of the font would make Safari crash. I thought that perhaps it was because I had declared the font in an incorrect way:
@font-face {
font-family: "VAG Rounded Thin Bold";
font-style: normal;
font-weight: bold;
src: url('/vag_rounded_thin_bold.ttf');
}
Do you see the problem here? I’ve declared the bold version to be bold—in other words, really, really bold—and initially thought that might have caused the crash. But when I changed the declaration to font-weight: 100;, the page would render—and then crash. We don’t have an answer to this problem & we’re still investigating the source of it. Once we’ve found out we’ll post the answer as an addendum to this article—but any suggestions from you would be most welcome.
So, that’s font embedding for you. A fairly mature declaration is hobbled in part by not having been used—the more usage it had, the more bug fixes we would have seen & the process would become more transparent. But at least this is a start.
Well, at least I know why Safari was crashing with the bold font now—and it doesn’t crash any longer. The solution is very obvious, actually—as things are always obvious once you’ve figured them out.
First, you declare the boldface version of the font:
@font-face {
font-family: "VAG Rounded LT Bold";
font-style: normal;
src: url('vag_rounded_thin_bold.ttf');
}
First of all, note that the font-weight is set to normal: you don’t want to make your bold font bold twice, as it then becomes very heavy. Now, in your stylesheet, style your strong (or, if you’re Old Skool, bold) with the font’s name, thus:
strong {
font-family: "VAG Rounded LT Bold", "Verdana", sans-serif;
font-weight: normal;
}
You see that we set the font-weight again to normal: otherwise, the font becomes entirely too heavy. Voilà: complete!
And don’t forget to repeat this effort for your Internet Explorer users on your EOT files.
Update (27 April 2009): There’s an interesting article by Tal Leming about embedding web fonts from a type designer’s point of view. It’s an interesting read & Tal makes some very good points that are worth serious thought. The idea of a new type format with the option of specifying a domain in the root table is an attractive one, but he’s conscious about what this means for legacy fonts (i.e., the exclusive support of a new format would break sites using previously available fonts).