If you want to create your own @font-face kits, you absolutely must check out Font Squirrel’s new @font-face generator tool. All you have to do is upload a TrueType or OpenType format font, and the generator spits out a zip file containing:
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.
Now that all major web browsers finally support the CSS @font-face declaration, embedding fonts in a web page is possible with just a few lines of CSS. In theory this means that web designers no longer need to limit their font choices to a handful of system fonts, and are free to use any typeface they please. In practice that freedom comes with a caveat: we are only allowed to use fonts with a license agreement that allows web embedding.
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.
I have always been slightly wary of CSS frameworks, put off by non-semantic class names, and a nagging feeling that CSS simply isn’t complex enough to require the hand-holding a framework offers.
But today I came across Scaffold, a CSS framework that made me rethink my position.
My friend John Gillespie recently wrote about the inauspicious origins of the Arial typeface, namely that it is a blatant copy of Helvetica. While I agree with the general thrust of John’s argument (I’m a self confessed Helvetica fanboy) I do think that Arial has one redeeming feature that deserves mention, especially in the context of web design: Arial renders better at small point sizes on Windows systems than Helvetica does.
Recently I was developing a website for a client whose primary export market is in China. Needless to say I was a little alarmed when my client’s representatives in China reported that they couldn’t access their new site.
My client has reps in both Shanghai and Beijing, neither of who could see the website, so I knew it wasn’t a localized issue. My immediate suspicion was that the infamous “Great Firewall of China” was to blame. Thankfully I was able to take a few simple steps to diagnose the problem and get the site up and running.
In my last post I outlined some of the problems that might arise from the proposed version targeting changes to Internet Explorer 8. My major concern was that by removing the motivation for web authors to update legacy sites, version targeting might hamper the adoption of modern web development techniques. During the week I have given some more thought to this issue, and it occurred to me that in Adobe Flash we have a fantastic real-world test case from which we might learn if version targeting is a viable strategy for a web browser.
When Dean Hachamovitch demonstrated in December that the forthcoming Internet Explorer 8 browser passed the Acid2 test in standards mode, there were calls for Microsoft to clarify if “standards mode” was the default setting for IE8. Last week it was announced on A List Apart and the Internet Explorer blog that IE8 will render pages using an IE7-level rendering engine by default, and that web developers must opt-in to take advantage of the new Acid2-compliant rendering mode.
When I started out as a web designer, content management systems belonged strictly to the realm of big budget websites. For everyone else, it was perfectly normal for a web designer to manually update a site whenever a change needed to be made. Clients didn’t expect a CMS to be included with their website, and web designers didn’t offer the option. Times have certainly changed, and in an age of blogs, Facebook, and MySpace, clients expect to be able to take control of their website’s content.
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.
Almost exactly a year ago I was musing about the possibility of dropping support for Internet Explorer 5 when testing websites. Time marches on, and now we are seeing calls to ditch support for IE6 too.
