Fonts, JavaScript, and How Designers Design
The W3C recommendation for CSS web fonts will be 7 years old soon. Why, after all these years, has typography for the web not progressed further? Why haven’t designers embraced linked, downloadable fonts in their designs?
We’ve spent a lot of time thinking about this as we’ve been planning and building Typekit. It certainly feels like things are different now – browsers are developing font support in open and interoperable ways; bandwidth has increased to allow for additional page elements. But perhaps most importantly, designers can start using fonts in their designs without having to change the way they work.
Tools for native web designers
We’ve been talking to a lot of designers — from hobbyists to some of the top professionals on the web — and we consistently hear them talk about their workflow. Very few designers these days use a unified suite of tools. Rather, they pull together what works, and spend the majority of their time writing markup by hand.
Any solution that hopes to bring rich typography to the web will need to accommodate multiple ways of working with the technology. When we thought about how Typekit could support all the ways designers and developers work, we started developing a number of features that would be valuable in addition to having access to fonts.
More control
Our goal from the very beginning has been to provide high quality fonts through a ridiculously easy to use service. That’s one of the reasons we use Javascript. By adding a line of code in your site’s pages, you’ll be able to use the Typekit site to control the following:
- Automatic CSS declarations. Once the code is in your page, you simply chose a font and decide what selectors to use. Reload and the font shows up. You don’t even need to edit your markup.
- Dynamic kerning and ligature control. Modern browsers are doing a great job at supporting @font-face linking, but it’s early yet. OpenType fonts have loads of capabilities and features like ligatures, kerning pairs, tabular numerals, and more. How all browsers on all platforms support those features varies, but we’ve been using Javascript to smooth some of that out.
- Fonts are loaded and rendered. Standards-based implementations also vary in the actual experience users have with the browsers. For example, how should pages reflow after the fonts are downloaded? What should happen while they’re downloading? Answers to these questions should be up to the site designer.
- Support for older browsers with fallbacks like Cufón, sIFR, or other techniques. For years now, clever designers and developers have created innovative workarounds to the lack of font support on the web. By using Javascript, we can offer selective support for these technologies.
Nuts and bolts
Sometimes we use automatic services and are happy they just work. Other times, we want to see behind the scenes and have as much control as possible. For some developers, every semi-colon and bit of whitespace is considered and checked. Adding linked fonts to your site shouldn’t affect this.
If, as a web designer or developer, you may want the option to simply hand-code your site, or have your markup and style programatically generated via a CMS. There are two ways you’ll be able to do this:
- Javascript API. If you’re comfortable writing script to control your pages, we’ll have an API you can use to define what selectors use each font. This gives you access to many of the features described above, but without having to incorporate the the Typekit web app into your workflow.
- CSS linking. If you really want direct access to fonts, then simply link to a hosted CSS file containing the @font-face definitions. You’ll have to forgo all of the additional features, but you’ll be as close to the fonts as you can be. Why not just give links to the font files directly? Because we believe that automatically serving EOT files for Internet Explorer is a core service we can provide. But we’re open to discussing even this. Let us know in the comments.
In either of these cases, you’ll be able to write CSS stacks using font names you get from Typekit.
Making it go
Our goal is to support designers and developers with tools that make it easier and more efficient to practice their craft. How will typography fit in? It may be too early to tell. A few years back, the shift from largely static pages to an Ajax-enabled web coincided with a commitment to building sites with web standards. This resulted in new tools, new skills, and new methods for doing our work. Adding great typography will only take us farther. We hope to be a part of this evolution.
22 Responses
Comments are closed.
I don’t think the issue is so much that designers haven’t embraced font-embedding in the past 7 years, it’s that browsers haven’t. Designers, and developers, have been using any possibly embedding hack given to us, whether sIFR, background images, or Cufon.
Really looking forward to see how the embedding works in Typekit, especially in regard to the point you made about page load and sequence. I’m also really curious, as I’m sure lots of others are, about how Typekit will make it so the CSS-linked files won’t be downloadable by anyone.
Can’t wait to see it!
I think Jeffrey suggested that Typekit will be an extension of sorts to the font-face declaration that we are already using (only now, it will be limited to the fonts available to Typekit rather than the client’s system). I presume there’s a script to parse through this declaration somehow and supply the browser with an OpenType font (or the Internet Explorer equivalent) to match the declaration.
If that’s indeed the case, I’m looking forward to more information on the size and performance of said script.
Good old CamelCase. Nice catch, Stephen. I updated the post.
Small nitpick: OpenType is spelled with a cap T.
Good old CamelCase. Nice catch, Stephen. I updated the post.
I appreciate the post Jeffrey, particularly that you confirm you’re using the @font-face declaration, and that you’re even open to the direct linking of .otf or .eot files, which some (read: purists) will no doubt prefer.
But, this implies that whatever type of DRM (for lack of a better word) you’ll be using is server-side rather than implemented through the JavaScript include. Is this true? I know that a lot of speculation has come up regarding your JS implementation and DRM, so inquiring minds will want to know.
Very good point Matt. I am also curious, as direct font linking implies a different model than I’d been lead to believe (JS-based licensing/DRM). Server-side makes more sense to me than a JS authentication key, but all of this is still very much in the air as far as public information goes.
Regardless, sensible automation of EOT vs OTF/TTF is a valuable feature in its own right. Anyone who’s attempted a combo @font-face/EOT solution in the past will greatly welcome a service that does it for them, even if it’s only serving freely licensed fonts.
Great news for the web development community! I`m also curious on how security of the font-file is handled and what the costs are for this service? (if any) are you thinking monthly, or just payment once?
Sorry for the inquiring mind 😉
I’m unclear about something – will you also be hosting sIFR files for selective fallbacks, or is that up to the designer/developer team to setup? How will that piece work from the developer’s point of view?
It’s the good shit like this makes me excited once more to be working on the web. Can’t wait to see your beast, @veen…
Hey Lorin,
We’re currently working out exactly how fallbacks will work. The goal is to make it seamless, or even automatic. For example, for a sIFR fallback we would generate and serve a .swf containing the desired font for you.
I’m surprised that you’re linking to sIFR 2… sIFR 3 has been rock solid (even if hard to use) for the last couple of years. Zeldman did the same last week. I feel like I’m missing something.
sIFR 2 the first link when searching – that’s probably why we both grabbed that. I’ve updated the link to the sIFR 3 wiki at http://wiki.novemberborn.net/sifr3/
sIFR 3 is still technically beta. Developers will not risk putting beta scripts on professional sites.
@Rebecca,
Professional _developers_ will be able to assess if a beta product is worth using in their _professional_ sites.
sIFR3 has been rock solid for years, though admittedly not straightforward to implement for someone without a minimal JavaScript knowledge.
Websites from high profile companies and high profile developers have been using it just fine.
@Veen, I don’t know if you already have, but should contact Mark Wubben. He knows this stuff. Has been debugging it for years.
It will be interesting to see which form of the Typekit service is the most popular. The system of defining the selectors associated with each font through a Typekit-hosted “dashboard” sounds like a nice value-add on paper, but my instincts tell me that experienced designers will want to keep all their styles in their own CSS code.
Direct-linking to font files would save one HTTP request (and DNS lookup) over the “hosted CSS file” solution. I can think of a few performance-minded developers for whom that would be a significant consideration. Supporting this mode would also be a nice “good faith” gesture that would settle a few nerves from designers who would feel uneasy about layers of “interference” between them and the products for which they are paying (the font files). Even if they didn’t end up using this option, they might find it reassuring that they could.
I’m also curious about what implementation methods turn out to be the most popular. I hope this information is released at some point, as it gives the rest of us a specialized look at how modern sites are built. While I would ideally retain direct CSS control, this might not be the case for everyone, and awareness of that would help guide future decisions.
I would personally prefer to get direct links to add to conditional comments (non-IE and IE) because I would want to use multibyte fonts, and given their size any small performance increase will help. This is assuming you offer multibyte fonts of course 🙂 I hope at least a couple of weights of the open-source Japanese font family M+ will be in the starting lineup!
The other main thing I wonder about is subsetting. One weight of M+ is ~550KB, but contains thousands of characters that won’t be used. Subsetting reduces this to a tenth on a typical page. Are you planning to offer a subsetting tool, equivalent to WEFT? Will there be some form of automatic re-subsetting when the page changes, even if it’s via trackback or something? This would add another layer of obfuscation on top of the base64 so should make foundries happy too.
Hmm, this looks like an excellent opportunity to shamelessly promote my font subsetting code! It’s not really a usable tool by itself, but it could be used in one – it aims to handle high quality fonts (preserving ligatures etc), and it seems to work fine in practice, and if there are any problems I could probably be motivated to fix bugs and missing features 🙂
I think integrating the font in the css sheet its more valuable, monstly because font its part of the visual, its not an effect. If you project your site with determined font, you think all the visual in the site with that: the margins, the paddings, the letter-spacing, and you’ll determine where that font will load in the css sheet, so I think the css sheet is the more apropriate place to link the font.
But what will determine the success of this project is the cross-browsebility. I, as many, project my sites, and first test in the latest versions of the browsers, but make it work in older versions, mainly in internet explorer 6 and 7, unhapply is still needed. We can’t just say to the clients of our clients that they have to atualise their browsers or they wont be able to see our site. Mostly, we can’t tell our clients that their clients has to do it. So, this is a fundamental part, becase we can’t just do two versions of the site, using image in one. So we prefer use images in both.
Other thing, It has to load fast. You must know an aplicative called ienpgfix. This is a little script that allow ie6 users to see tranparent png in the sites. But it make even in broadband the site a little, very little, but still considerable slow to load. And it kills this script.
The iniciative is really GREAT! Hope to use it as soon as possible!
If there is one place where all the solutions fall, is supporting RTL (right-to-left) languages and foreign fonts.
I would really like to see one web font project that will not neglect supporting RTL
Hi, what fonts are available? Or is it any font. Like if I have something in my fonts folder, can I upload that and use it on my websites with this?
When one of the major browsers needs an entirely proprietary and seperate font format to make @font-face linking possible, and when you have to download, install and use another piece of software to even create the fonts, especially when that piece of software only runs on one of the two operating systems commonly used in web design, and especially when even on that platform it’s almost unusably confusing, unstable and creepy, then of course we’re still screwing around with SIFR.
Will somebody please make a drag-and-drop ttf/otf -> .eot app? Then we can all get on with our lives. For the better part of a decade, Microsoft has held us back from doing good type on the ‘web. There’s a command-line solution in linux, what about something that Mac and Windows people can get into?