Local Web Development with Adobe Typekit

My bread and butter is really front-end scripting (JavaScript) and server side technologies (c#, WebApi, MVC, etc), so I feel like any time I really venture into the world of design, I learn something new — which is great!

While working with a designer on a new website, she requested we use Adobe Typekit to make better use of some nicer fonts on the web. Using great looking fonts has long been a challenge, but Typekit seems to offer a pretty slick solution to give you better control. One quick aside, I noticed that my Ghostery plugin doesn’t really like Typekit fonts and by default blocks typekit scripts. So be aware that users may not see your glorious fonts anyway if you use Typekit and they have Ghostery installed. If you want to know more about Ghostery and Typekit, here is a resource for you.

Using Typekit on Your Webpage

Now, in general, Adobe has made it pretty simple to use Typekit with a website. The basic steps are as follows:

  1. Create a “Kit”. On typekit.com (after logging in), there is a menu item called “<> Kits” that has an option “+ Create new kit”. A kit is a grouping of fonts you would like to use on your website. Once created, this kit will be assigned a unique ID that will be referenced in the Javascript Adobe provides for you to embed in your site.
  2. Add some fonts to your kit. Navigate to your library and find a font you like. Select that font and you will be given an option to “Add to Kit” (there is a button that reads “Web use: Add to Kit”). Once you have added all the fonts and variants to your kit, you are ready for the next step
  3. Add domain(s) to your kit settings. To do this, navigate back to your kit (using the “<> Kits” dropdown menu in the header) and choose “Kit settings”. From here, you can specify any domains where you will be using this kit (among other options). For development purposes, you can enter “localhost”. In theory this is all you have to do to enable Typekit to work with these domains. I found some obstacles in that, hover. Be sure to save your changes.
  4. Publish your kit. After everything is correct in your settings, go back to your kit page and click the publish button in the lower right corner. It says it can take a couple of minutes for changes to become active, so be a little patient.
  5. Grab the embed code (JavaScript) and put it into your site’s head. Right next to where you updated the settings, you can see a “Embed Code” link that will present a popup with your default code that should look something like this:
    <script src="https://use.typekit.net/myKitId.js"></script>
    <script>try{Typekit.load({ async: true });}catch(e){}</script>

    Where the javascript file “myKitId.js” is replaced with whatever kit ID was assigned to your kit.

In theory, this is where everything should just work. All you need to do is use your fonts in CSS as they are named (all lowercase, replacing spaces with hyphens). An example of a page is as follows:

        <script src="https://use.typekit.net/myKitId.js"></script>
        <script>try{Typekit.load({ async: true });}catch(e){}</script>
        <style type="text/css">
            body { font-family: sans-serif; }
            .myFont { font-family: "futura-pt"; }
        <p>This text should have font-family sans-serif</p>
        <p class="myFont">This text should have font-family futura-pt.</p>

Of course, you have to replace font-family with whatever fonts are defined in your kit (and replace the Kit ID), but you should see those two sentences with different fonts. If you don’t, then something isn’t right.

Figuring Out How Typekit Loads Fonts

I saw the fonts load correctly on my public domain, but they wouldn’t show on my development machine (using localhost).

I noticed there was a “Show Advanced” link¬†on Typekit’s “Embed Code” page, which displayed a self-executing JavaScript function that had the added benefit of asynchronous loading. All this “advanced” code really does is load an external JS file into a script tag inserted into the head and provides some CSS classes to hide some page flicker before the Typekit fonts are displayed. There is a pretty good explanation of the differences between the default and advanced Embed code here: https://helpx.adobe.com/typekit/using/embed-codes.html. Unfortunately, this didn’t have anything to do with the problem at hand.

Now, to really figure out why this wasn’t working, I pulled up Firebug and took a look at the HTTP requests in the “Net” tab. I could see that the request to my Typekit JavaScript file wasn’t completing. While I couldn’t figure out why, I tried pasting the url of the request into my browser, and it loaded the Javascript up for me. The javascript displayed was compressed and pretty hard to interpret. I decided to save it and load it locally to see if it would make a difference.

Unfortunately, still no luck. But what I could see now, is that inline CSS was being added to the head of my document. The CSS looked like the below:

@font-face {
    font-family: "futura-pt";
    font-style: normal;
    font-weight: 400;
    src: url("urlToFont") format("woff2");
@font-face {
    font-family: "futura-pt";
    font-style: normal;
    font-weight: 300;
    src: url("urlToFont") format("woff2");

Storing the Fonts Locally and Serving them Up

It was at this point that I knew I could work around Typekit’s issues. By navigating to the urls in src attribute of the @font-face selectors, I was presented with a file to download. The file downloaded as just “l” (no extension). I guess the file extension would be .woff since the format listed in the CSS file was “woff2”. After downloading each font file and renaming them to something that represented what the font was (“futura-pt-book.woff” and “futura-pt-light.woff”), I put them in a “fonts” directory in my development folder.

Next, I created a fonts-local.css file that contained the CSS code that was being generated by Typekit (see the code snippet above) and stuffed a reference to that CSS file into the head of my document. I replaced the src: urls in the stylesheet with the path to the woff files in the directory I created above.

Finally, in my site template’s html head section, I removed the script calls to Typekit altogether and just referenced my local files.

This technique isn’t exactly ideal, because any changes I make to the kit won’t be propagated to this page (also, your web server has to be configured to serve woff files). However, it allows you to see your fonts locally during development if Adobe’s recommendations don’t work, and also gives you an option if you’re concerned about the whole Ghostery plugin / Adobe privacy concerns issue.

You might be asking, “Why didn’t you just download the .woff files from Typekit?” and skip all the in between, but the problem is that the .woff files don’t seem to be available for direct download. That’s probably because now I could take these woff files and use them with any site or distribute them (illegally), and I think they’re trying to control that kind of behavior as much as possible.