We’ve noticed a recent focus on web performance in blog posts, tweets, and support tickets, so we thought it would be a good time to revisit Typekit embed codes. There are two recommended ways to embed Typekit on your web page:

  • Basic embed code (default)
  • Advanced embed code

The embed codes can be found by launching the Kit Editor and selecting “Embed Code” in the upper right corner. The basic embed code is displayed by default; use the “Show advanced” link to switch to the asynchronous version.

embed

The basic embed code is recommended for most customers. The advanced embed code is for people who wish make their sites more resilient by loading resources asynchronously. This also requires some extra work to avoid the Flash Of Unstyled Text (FOUT) by modifying your CSS.

Default versus Advanced embed code

The default embed code blocks rendering of the page until the kit JavaScript has finished loading. We recommend this method because it will immediately insert @font-face rules into your page through a stylesheet (which, depending on your browser, may contain embedded fonts.) If the browser detects a @font-face rule but the font file isn’t available yet, it hides the text by default. This allows you to easily embed fonts in your page while giving you basic control over the FOUT. Our global Content Distribution Network (CDN) ensures speedy delivery of the kit JavaScript and fonts, so the default embed code will work well for most users.

The benefit of the advanced embed code is that it won’t keep the page from rendering while the kit JavaScript is loading. The downside to this is that the browser can decide to start rendering your site before the fonts are available. Font events will not be available if the browser decides to start rendering the page before the kit JavaScript has loaded. This is also the reason we recommend putting the embed code in your head and not at the end of your body. This ensures the code is loaded asynchronously while still being able to control the FOUT.

Common misconceptions

It is important that you only pick one of these methods. Using both at the same time will degrade the performance of your website. If you are using other font services together with Typekit, we recommended you use the open source Web Font Loader library instead of the Typekit embed code.

There is also a common misunderstanding that if you wish to use JavaScript font events, you’ll need to load your kit using the Web Font Loader. In fact, the Typekit JavaScript includes its own version of the Web Font Loader code and gives you the same access to font events. The advantage of using the Web Font Loader over the basic or advanced embed code is that it allows you to load fonts from more than one font service at the same time.

Using Typekit with “optimising” server modules and CDNs

We’ve noticed an increased usage of “optimising” server modules and CDNs, such as PageSpeed, CloudFlare Optimizer and Yottaa Site Optimizer, that attempt to automatically load JavaScript asynchronously by rewriting your web pages and JavaScript on the fly. We recommend exempting the Typekit embed code from these CDNs and proxies, as they will usually make it more difficult to reliably control the FOUT. By trying to modify the page to load the kit JavaScript asynchronously, these changes actually delay the kit’s ability to set the wf-loading class, which means your page can start rendering without fonts and without font events to control the FOUT. You should exclude the kit JavaScript from automatic changes if you are concerned about the FOUT appearing on your pages.

If you have any questions about how to embed Typekit on your website, don’t hesitate to contact Typekit support at support@typekit.com.

More reliable font events

February 5, 2013

We’re often asked by developers why Typekit uses JavaScript to load web fonts. Of the many advantages, one leading benefit is that JavaScript can monitor the page, detect the various stages of font loading, and provide the means for a developer to respond. This gives the developer the power to consistently control the Flash of Unstyled Text (or FOUT), measure web fonts for dynamic layouts, and more.

Typekit provides these capabilities through font events, which detect the state of fonts and allow developers to work with loading, active, and inactive CSS class names and JavaScript callbacks. While font events are fairly reliable, the WebKit rendering engine has had a long-standing bug which can cause the active event to fire too early. While the bug is fixed in recent versions, many browsers on mobile and desktop still have this problem.

Today we’re happy to announce that we’ve created a workaround which has been incorporated into the open-source webfontloader library as well as all newly-published Typekit kits. To take advantage of this fix in your kits, simply head to typekit.com and republish. To learn more about the bug, our workaround, and the future of web font loading detection, read on.

Font loading detection

Web browsers today don’t have a native API for telling the page when web fonts are loaded and ready for use. We work around this missing functionality by inserting an element into the DOM and retrieving its width and height. Then we add the font we are trying to load to the ‘font-family’ property of the element and set up a timer to periodically check the width and height of the element again. If at any point the width and height are different from the original size, we assume that the font has loaded. If no change is observed within five seconds, we assume the font has failed to load.

An additional complexity is the possibility of a metric compatible font being loaded. A metric compatible font is designed to have identical width and height for each glyph compared to another font. An example of this is the Liberation font family, which was designed to be metric compatible with Arial, Times New Roman, and Courier.

While metric compatible fonts are rare, they will actually cause a false negative in our detection strategy. From the perspective of our element, the width and height never change if the local font and the web font have identical metrics. The font detection code will wait until the timeout and then assume the font has failed to load.

To counteract metric compatible fonts, we introduce another element with a second local font fallback that has different metrics from the one we used before. This means that if the web font loads, both elements have the same size; if it doesn’t load, at least one of the elements will have a different size.

font-measuringA pair of elements used for font detection. The red borders show the boundaries of each span, which is where width and height are measured. Serif and sans-serif fallback fonts are used to counteract metric compatible fonts.

WebKit bug

While this size detection scheme works smoothly in most browsers, a bug in older WebKit versions makes it unreliable. WebKit versions that have this bug will switch to a “last-resort” font while loading web fonts. The last-resort font is the font you get when the browser does not know which font to use. This means it will not use the normal font fallback stack, and instead choose a platform-specific font.

Further complicating matters, on some platforms the browser will also try to choose a last-resort font based on the last item in the font stack that first references the web font. Other platforms may hard-code a default last-resort font, or use a strategy for selecting a last-resort font where selected unicode ranges map to different fonts.

This means that in our DOM element monitoring scheme, we’ll perceive up to two different changes in width and height. If we happen to measure the element while the last-resort font is in use, and the width or height is different, we’ll interpret that the web font has been loaded before it’s actually ready.

Workaround

We work around the bug by maintaining a list of last-resort fonts and measuring the width and height of each. If a change in width and height occurs on the DOM element and the bug is present, we’ll compare the width and height with each entry in our list of last-resort fonts. If a match is found, we know that the size change is probably not due to the web font loading, but rather to the WebKit bug switching the font to the last-resort font.

However, there is a problem with this approach when the web font we’re trying to load is metric compatible with one of the last-resort fonts. In this case, we’ll see the first change in width and height when the last-resort font becomes active, but never a second when the web font is ready.

To mitigate this problem, we’ve added a special case to the timeout. If the bug is present, and the font detection code times out while the width and height match the last-resort width and height, the webfontloader will assume the timeout is due to the last-resort font and web font having identical metrics.

Looking ahead: Native font events

The CSS3 Fonts Module recently introduced a new interface on the document object called fontloader. This interface can be used to explicitly load web fonts, or to notify when a font has loaded (or failed to load). This means that going forward, as browsers more regularly feature built-in support for detecting all the phases of web font loading, our workaround won’t be a required step.

The fontloader interface is pretty straightforward, and it will appear familiar as it was partly influenced by the design of the open-source webfontloader library that Typekit collaborates on and uses in kits. It has three properties called onloadstart, onload and onerror for when a font starts loading, when it finishes loading, and when it has failed to load.

document.fontloader.onloadstart = function (e) {
  console.log(e.fontface + ‘ has started loading’);
};

document.fontloader.onload = function (e) {
  console.log(e.fontface + ‘ has finished loading’);
};

document.fontloader.onerror = function (e) {
  console.log(e.fontface + ‘ has failed to load’);
};

It is also possible to use the fontloader interface to manually trigger loading a font from JavaScript. There is currently no browser support for the fontloader interface, but we’ll update webfontloader to use the native font events as soon as it is implemented in browsers.

This is our fourth and final post in an ongoing series about using font events for better control over how web fonts load. Read the first post for an overview of font events, the second post for information on controlling the FOUT, and the third post for information on fallback fonts and styles.

In the past several posts in this series, we’ve discussed how to use Typekit font events in your CSS to control the FOUT and apply fallback fonts and styles. But there’s another aspect that we haven’t yet discussed: font events can be used via JavaScript callbacks as well.

Screenshot of the promo on the Typekit homepage fading in after fonts have loaded
Font event JavaScript callbacks in action on the Typekit homepage.

Why would you want to use font events in JavaScript? We’ve already discussed using font events in CSS to avoid the flash of unstyled text. However, if you have very large text set in a web font, such as in a module promoting a product, the sudden appearance of that text may be jarring. In this case, you may want to fade in the text gradually after the font is loaded (an effect that wouldn’t be appropriate for an entire page of body text). This is where font event JavaScript callbacks come in handy. In fact, we use font events and JavaScript to achieve a fade-in effect on the Typekit homepage.

The three main font events (loading, active, and inactive) are available in JavaScript via callback functions that you pass in when you call Typekit.load. Here’s the generic example of setting up callback functions for each of these three font events:

<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script>
<script type="text/javascript">
 try {
   Typekit.load({
     loading: function() {
       // Javascript to execute when fonts start loading
     },
     active: function() {
       // Javascript to execute when fonts become active
     },
     inactive: function() {
       // Javascript to execute when fonts become inactive
     }
   })
 } catch(e) {}
 </script>

Let’s take a look at a simple example page that demonstrates one way to accomplish the fade in behavior using these JavaScript callbacks. Our example uses the jQuery JavaScript library to make things like DOM manipulation, hiding, and fading elements easy, but you could just as easily use another library. Here are the basic steps necessary to achieve this effect:

  1. As soon as the DOM is ready, hide the web fonts by applying visibility: hidden.
  2. Once the fonts have finished loading, remove visibility: hidden and fade in the text (using jQuery’s .fadeIn).
  3. If the fonts don’t load successfully, remove visibility: hidden. We can also apply fallback styles in CSS using the wf-inactive class (as we discussed in our previous post on fallback styles).

Time-lapse capture of the example page fade in Mac Firefox and Windows IE8
Time-lapse capture of the example page fade: Mac Firefox above, Windows IE8 below

Unfortunately, when you look at this example in Internet Explorer, you’ll notice that there are some jagged black outlines around the edges of the characters as they fade in. This is because IE8 and below don’t support CSS opacity, but instead use a proprietary filter. The upcoming release of IE9 will reportedly support CSS opacity and should address this issue. However, if we want to avoid these jagged outlines now, we need to make sure that browsers that don’t support CSS opacity use an alternate effect, such as showing the text immediately. jQuery provides a handy jQuery.support.opacity property that we can use to test if a given browser supports CSS opacity.

Pulling it all together, here’s the JavaScript code from the example page that loads jQuery, loads our kit, and then sets up the fade-in behavior (while avoiding that effect in browsers that don’t support CSS opacity):

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js"></script>
<script type="text/javascript" src="http://use.typekit.com/lmu3khn.js"></script>
<script type="text/javascript">
  (function() {
    $(document).ready(function() {
      // As soon as the DOM is ready, make the example invisible
      $('#example').css('visibility', 'hidden');
    });
    try {
      Typekit.load({
        active: function() {
          // As soon as the fonts are active, fade in the example
          // Don't fade in browsers that don't do proper opacity, like IE
          if (jQuery.support.opacity) {
            $('#example').css('visibility', 'visible').hide().fadeIn();
          } else {
            $('#example').css('visibility', 'visible');
          }
        },
        inactive: function() {
          // If the fonts are inactive, just show the example
          // You can apply fallback styles using the wf-inactive class in your CSS
          $('#example').css('visibility', 'visible');
        }
      })
    } catch(e) {}
  })();
</script>

Now we’ve progressively enhanced our page for browsers that support CSS opacity with a fade-in effect that makes the appearance of our web font less abrupt. Again, this type of effect is most appropriate for small amounts of large text, not for an entire page of body text. Typekit font events give you the control you need, allowing you to conditionally trigger CSS styles and JavaScript code as the fonts are loading.

This is the last post in our series on font events. If we missed covering an application of font events that you’re interested in, let us know in the comments. And as always, you can email Typekit support with any questions. Thanks for tuning in!

This is our third post in an ongoing series about using font events for better control over how web fonts load. Read the first post for an overview of font events, the second post for information on controlling the FOUT, and the fourth post to learn about JavaScript callbacks with font events.

Most browsers and operating systems in use today support web fonts, and Typekit was designed to make supporting each of these different combinations easy. As a conservative estimate, more than 97.5% of the people who visit sites with Typekit have a compatible browser and are able to see web fonts.

But what about the other ~2.5% of visitors who have an older browser that doesn’t support web fonts? Or the visitors who have a user preference that disables web fonts? What will they see when they visit your site? This is where fallback fonts and styles come in. Typekit font events give you more control over the fallback fonts and styles for the few users who don’t see web fonts.

Why are font events necessary for defining fallbacks? After all, you can use the vanilla CSS font-family property to specify a list of fonts to use (called the CSS font stack). If the browser can’t find the first font, then it will use the second font, and so on down the list. It’s always a good idea to pick a fallback font that’s as close to your chosen web font as possible, but there are often minor differences in optical size and appearance. As a result, you may want to serve slightly different styles depending on whether the web font or the fallback font is used, and that’s where font events come in.

Setting fallback fonts in the Kit Editor and directly in your CSS
Examples of setting fallback fonts in the Kit Editor or directly in your CSS.

How do you choose and set your fallback fonts? Your fallback font stack should contain at least one fallback font that is uniformly available across platforms (like Georgia or Arial), followed by a generic font-family name (like serif or sans-serif). W3schools has a list of fallback fonts that are available on most platforms. So, for example, if I choose Adobe Minion Pro as my Typekit font, then my fallback stack could be "Times New Roman", serif. You can set your fallback fonts in the Kit Editor under “CSS Stack,” or you can include the Typekit fonts and fallback fonts directly in your own CSS, like so:

.post-body {
  font-family: "minion-pro-1", "minion-pro-2", "Times New Roman", serif;
}

Let’s look at a real-world example of using fallback fonts and styles. I recently added Typekit to the website that I maintain for Rimrock College Consulting. I chose Lapture Subhead by Just Another Foundry for the headings and navigation, since it has a distinguished, almost collegiate feel. Since Lapture is a wider serif font, I chose Georgia as my fallback font, followed by a generic serif family name. To keep things simple, we’ll just look at styles that apply to the site navigation.

Navigation for Rimrock College Consulting with web fonts active
Navigation for the Rimrock College Consulting website with web fonts active.

First, I wrote CSS to apply my Typekit fonts and fallback fonts to the menu. I also included some font-related styles to adjust the size, line-height, weight, and other properties:

#menu {
  /* Fonts for the menu */
  font-family: "lapture-subhead-1", "lapture-subhead-2", Georgia, serif;

  /* Font styles for the menu */
  font-size: 20px;
  font-style: italic;
  font-weight: bold;
  line-height: 1.2;
  text-align: right;
}

After adding these styles, I was happy with the way the menu looked when web fonts are active. But what about when web fonts are inactive? To test it, I used the Firebug Firefox extension (or the developer tools in Chrome and Safari) to edit the live CSS and remove the Typekit font names ("lapture-subhead-1", "lapture-subhead-2") from my font-family definition.

Comparing the navigation with web fonts and unstyled fallback fonts
Comparing the navigation with web fonts (left) and unstyled fallback fonts (right).

Removing these fonts from the stack allows me to see what my page will look like when the fallback fonts are used. Georgia isn’t a bad fallback, but at a given font-size it looks bigger than Lapture. In order to make my fallback fonts look less obtrusive, I needed to add fallback styles for a smaller font-size and increased line-height when the fallback fonts are used:

#menu {
  /* Fonts for the menu */
  font-family: "lapture-subhead-1", "lapture-subhead-2", Georgia, serif;

  /* Font styles for the menu that look good with Georgia */
  font-size: 16px;
  font-style: italic;
  font-weight: bold;
  line-height: 1.5;
  text-align: right;
}

.wf-active #menu {
  /* Lapture needs a bigger font-size and smaller line-height compared to Georgia */
  font-size: 20px;
  line-height: 1.2;
}

Comparing the navigation with web fonts and fallback fonts and styles
Comparing the navigation with web fonts (left) and fallback fonts and styles (right).

Now I’ve got a menu that looks almost as good with my fallback fonts as it does with the Typekit fonts, and it’s easy to swap between the two (by removing and adding the wf-active class). It was a little bit more work, but I’ve ensured that users who can’t see web fonts (due to an older browser or a user preference) still get styles that I’m happy with.

In the next installment of our font event series, I’ll talk about using font events in JavaScript. We’ll use JavaScript-based font event callbacks to add additional behavior to a page, like making the headings fade in once web fonts are done loading. Until next time!

Update (Nov 12, 2010): As nimbupani pointed out in the comments, there’s a much better resource for choosing fallback fonts available at Code Style. They have data on which fonts are installed across Windows, Mac, and Linux machines. Use their very helpful font stack builder tool to see the percentage of users on each platform that each font in your fallback stack will cover (see this example). I’ve already found this resource to be extremely helpful. Check it out!

This is our second post in an ongoing series about using font events for better control over how web fonts load. Read the first post for an overview of font events, the third post to learn how to control fallback fonts and styles, and the fourth post to learn about JavaScript callbacks with font events.

Screenshot of before and after fonts have loaded on the blog A Working Library
An example of FOUT—before and after fonts have loaded—on the blog A Working Library.

We’ve designed Typekit to deliver fonts to web pages as quickly and efficiently as possible. We strive to minimize download size, use as few requests as possible, and distribute fonts around the globe using a CDN so there’s always a server nearby. We also cache fonts so that subsequent page loads have web fonts available immediately. However, despite our best efforts, there may occasionally be users for whom fonts load more slowly.

In these cases, Typekit users are most often concerned about their visitors seeing an effect commonly know as the FOUT, or the flash of unstyled text. You may have noticed the FOUT before: it’s that brief flash of text in a default font before the web fonts have finished loading.

In fact, whether or not you see any FOUT when using web fonts differs based on which browser you’re using. Thanks to research from Steve Souders, Paul Irish, and others, the differences in how browsers load web fonts have been carefully characterized. Here’s what happens when a web page with Typekit loads in each major browser:

  • Internet Explorer: Nothing is rendered until the web fonts have finished loading. You shouldn’t see any FOUT.
  • Chrome / Safari (WebKit): Text set in a web font isn’t rendered until that web font has finished loading. You shouldn’t see any FOUT.
  • Firefox: Text set in a web font is rendered using the fallback font until that web font has finished loading. You may notice FOUT depending on your connection speed.

So when we talk about controlling FOUT, Firefox is the browser that we’re concerned with. Firefox may decide to change in the future to hide text until web fonts have loaded (like WebKit-based browsers). But thanks to Typekit’s font events, we can make Firefox behave just like WebKit browsers today.

Using font events, we can add CSS styles to hide text that uses web fonts until after they’ve loaded, eliminating the FOUT. This makes Firefox mimic the rendering behavior of Chrome and Safari. However, we also want to make sure that we leave text visible for users that can’t load web fonts due to an older browser, user preference, or disabled JavaScript. This allows our websites to degrade gracefully so that everyone can still see the content, regardless of the style.

Let’s say that I have a blog, and I’m using Typekit fonts for my blog title (which has a class of blog-title) and post titles (which have a class of post-title). Using CSS and font events, I want to hide the blog title and post titles in all browsers (including Firefox) until the fonts have finished loading. Assuming that I already created a kit and have assigned web fonts to the .post-title and .blog-title selectors, here’s what I would add at the end of my blog’s <head>:

<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>
<style type="text/css">
  .wf-loading .blog-title,
  .wf-loading .post-title {
    /* Hide the blog title and post titles while web fonts are loading */
    visibility: hidden;
  }
</style>

While fonts are loading, the Typekit JavaScript adds the wf-loading class to the <html> tag. This CSS uses that class to hide the blog and post titles. Once web fonts are detected as active (or inactive), the wf-loading class is removed and the titles become visible again. For users who have JavaScript disabled, the wf-loading class is never applied in the first place, so the titles always remain visible.

By taking advantage of font events in our CSS, Firefox will load web fonts just like WebKit-based browsers such as Chrome and Safari, and we ensure that users won’t see an unsightly flash of unstyled content.

In the next installment of our font event series, I’ll talk about how to maintain control over the appearance of your website for users that can’t load web fonts at all. We’ll use CSS and font events to style appropriate fallback fonts so that the page gracefully degrades, maintaining readability, layout, and even consistency in style. See you next time!

This is our first post in an ongoing series about using font events for better control over how web fonts load. Read the second post to learn how you can use font events to control the FOUT, the third post to learn how to control fallback fonts and styles, and the fourth post to learn about JavaScript callbacks with font events.

We’ve noticed that the people who use Typekit really pay attention to the details: which web fonts go well together, how they render on different platforms, and how they affect the way their site loads. We love this passionate attention to detail, and we’re happy to provide tools that give our users more of the control they crave. One tool we provide is our Typekit font events, which come baked into every kit we serve.

Screenshot of font event class names on the site for Jax Vineyards
Font event class names—seen with Firebug—on the site for Jax Vineyards.

When we first built Typekit, we made an important decision to use JavaScript, which, while still standards based, gives us far more control over how fonts are loaded. That decision, in turn, led us to collaborate with Google to develop font events. Font events give you control over how your site is displayed while fonts are loading or inactive.

We deliver fonts as quickly as we can to as many platforms as possible, but there may occasionally be users for whom fonts load slowly or not at all. The reasons for this can be outside of our control — like a slow connection, an old browser or operating system, or a user preference that disables web fonts. In these cases, you want your page to degrade gracefully, ensuring that the content is still accessible and minimizing distracting changes to your layout. Font events provide the additional control that makes this graceful degradation possible. They let you change the style or behavior of your site in response to slow loading or inactive web fonts.

Here’s how we do it: our JavaScript performs a check while your page is loading, rendering a bit of text off-screen in each font contained in your kit and comparing the width of that text against a reference width. This allows us to detect that a font is active as soon as it is successfully rendered on the page. If the rendering doesn’t change within a certain amount of time, we report that fonts are inactive.

There are three main font events that are available with Typekit’s standard embed code:

  1. Loading: the fonts in your kit are in the process of loading
  2. Active: the fonts in your kit are loaded and we’ve verified that they’re rendering on the page
  3. Inactive: the fonts in your kit aren’t rendering, either because this platform doesn’t support web fonts or they couldn’t be loaded

These font events are made accessible to web developers in both CSS and JavaScript.

In CSS, font events are made available via special class names that are appended to the HTML tag. You can write CSS that is applied to your page during each of these phases:

<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>
<style type="text/css">
  .wf-loading {
   /* styles to use when web fonts are loading */
  }

  .wf-active {
   /* styles to use when web fonts are active */
  }

  .wf-inactive {
   /* styles to use when web fonts are inactive */
  }
</style>

These font event class names can be used to control how your page looks before the fonts are loaded (avoiding a problem known as FOUT, or the flash of unstyled text). They can also be used to include fallback styles if web fonts should fail to load for any reason.

Font events are also available from JavaScript, in the form of font event callbacks. You can define these callbacks when you call Typekit.load:

<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script>
<script type="text/javascript">
 try {
   Typekit.load({
     loading: function() {
       // Javascript to execute when fonts start loading
     },
     active: function() {
       // Javascript to execute when fonts become active
     },
     inactive: function() {
       // Javascript to execute when fonts become inactive
     }
   })
 } catch(e) {}
 </script>

These JavaScript font event callbacks allow you to control the behavior of your page as web fonts load. For example, you could fade in a piece of text once a font has loaded, or recalculate sizes for a complicated mathematical layout.

In the coming weeks, I’ll write more about some common ways that you can use Typekit’s font events, such as controlling the FOUT (flash of unstyled text), providing fallback fonts and styles that keep your layouts from breaking, and fading in a piece of text once fonts have loaded. With a little extra attention to detail, Typekit can help you give every visitor to your site a more beautiful experience.

Typekit Font Events

May 14, 2010

Web fonts may be the best thing to happen to web design in years, but that doesn’t mean there aren’t some tricky issues to overcome. One of the most annoying things is dealing with what’s become known as the FOUT or ‘Flash of Unstyled Text’. It’s what happens in some browsers while waiting for fonts to download.

Typekit is introducing Font Events to put you back in control when using web fonts. It’s simple: Typekit will tell you when the fonts have become active. You can do cool things with that information, like

  • Control the FOUT
  • Normalize font metrics between the fallback font and the web font
  • Show a loading message
  • Anything!

To get started, check out the documentation, then republish your kit. Have fun, and let us know what you think!