Tom Lauck’s

A First Date with TypeKit


Several weeks ago, I found myself in a friendly debate with a co-worker over the handling and future of fonts through the web browser.  Hours later, a TypeKit invite landed in my inbox; how coincidental.

Vegetarian Chicken

To break down what is happening with TypeKit, Jonathan Snook has a nice article that articulates the licensing limitation and techniques needed for successful @font-face embedding – TTF/OTF, EOT, and SVG.  These are the basic tenets of utilizing @font-face from a technical standpoint, minus TypeKit’s JavaScript for legal embedding and SVG.

@font-face {
	font-family: 'GothicCustom';
	src: url("LeagueGothic.eot");
	src: local('League Gothic'),
		url("LeagueGothic.svg#lg") format('svg'),
		url("LeagueGothic.otf") format('opentype');

Jonathan Snook – Becoming A Font Master

He also encapsulates the fact that font issues break down to essentially two buckets, browser compatibility and licensing.  This is a huge differentiator for TypeKit – all fonts based on your subscription level are properly licensed.  This does not come without a caveat unfortunately.  Rather than choosing from fonts common to designers such as Frutiger, Futrura, Univers, etc – TypeKit presents a list of imitations.  And thus I suddenly felt like I was looking at a Chinese buffet dish labeled as “chicken” even though it’s not – you’re not fooling me!

Rationale: Who cares if it’s not real chicken, Chinese “chicken” tofu kind of tastes and feels like real chicken so stop complaining – it’s healthy for you.  Translation: TypeKit font families aren’t quite what you are used to but most of them are close enough – and they are fully licensed, everyone is happy.

The Vegetarian Dies of Malnutrition

If you are not a fan of JavaScript and are just interested in a purist CSS only solution, you should really leave now – yes, TypeKit relies on JavaScript just as most of its competitors. Comparing apples to apples (in this case TypeKit vs sIFR), TypeKit’s JavaScript footprint is a bit smaller than sIFR’s ~10k compared to sIFR’s ~20k.  But wait – how exactly is the font getting inserted into the page – it’s not like we are using a system font that can just be accessed at the OS level?  As it turns out, each font in TypeKit is upwards of 100k and in my small use case, for 2 fonts in my kit, I was hitting 240k. Now you can trim this down depending on the font you choose and exact character sets, however, this was what the TypeKit editor defaulted to for my demo site’s needs.  


Comparing apples to apples again, in my small use case for 2 separate fonts via a single SWF file – oh and these were my EXACT brand fonts, not imitations – I was hitting about 50k.  This could certainly explain the load and render delay many (not just myself) have been experiencing with TypeKit.  Another contributor to render time could be the fact that TypeKit requires their script to load in the <head>.  This is contradictory to Yahoo’s optimization guidelines and progressive loading – it forces that 250k to be rendered before anything else on page can be rendered.  Did I mention TypeKit costs money too?

File size and loading optimization aside, browser compatibility – the overriding limiting factor we usually face is also an interesting study. Obviously there is always a significant margin in these statistics, but for reference here is the current browser usage share and Flash penetration:



Adobe Systems, Inc.

In some of my personal findings with TypeKit, Chrome is a no-go, along with earlier versions of Firefox, IE, Opera, and Safari and sporadic behavior in all of the above. And I’m not the only one.  Again TypeKit is still in beta, so they get a little bit of a freebie here, but the fact remains that @font-face has remained somewhat elusive for so long, for so many reasons, and to think that it is solved right now would be a bit naïve.  By comparison, Flash replacement is somewhat bulletproof these days as Flash has become somewhat ubiquitous.

Give Me My Meat and Potatoes

Indeed, it is hard to argue the need for better handling of non-standard web fonts.  My personal philosophy around non-standard web fonts has always been holistic in nature – sIFR is good, but it still doesn’t solve the problem fully and neither does Cufon for that matter – so I often err on the side of creative use of standard web fonts. TypeKit is definitely a progressive effort to solve the problem of non-standard fonts in the browser.

Maybe I’ve been abused by bad technology hacks in the past, but I think the real issue goes deeper than our siloed world of web browsers and markup.  Which brings me to a conclusion of why we have been trying to implement non-standard web fonts in the first place: designers want finite control.  And this is the very reason why there is such a difference in standards between OS’s standard fonts and more importantly how they are rendered – Apple typically sides with the font designer and Microsoft does not.

The difference originates from Apple’s legacy in desktop publishing and graphic design. The nice thing about the Apple algorithm is that you can lay out a page of text for print, and on screen, you get a nice approximation of the finished product. This is especially significant when you consider how dark a block of text looks. Microsoft’s mechanism of hammering fonts into pixels means that they don’t really mind using thinner lines to eliminate blurry edges, even though this makes the entire paragraph lighter than it would be in print.

The advantage of Microsoft’s method is that it works better for on-screen reading. Microsoft pragmatically decided that the design of the typeface is not so holy, and that sharp on-screen text that’s comfortable to read is more important than the typeface designer’s idea of how light or dark an entire block of text should feel. Indeed Microsoft actually designed font faces for on-screen reading, like Georgia and Verdana, around the pixel boundaries; these are beautiful on screen but don’t have much character in print.

Joel Spolsky – Font smoothing, anti-aliasing, and sub-pixel rendering

Rather than standardizing on one solution for the masses, OS manufactures, browser developers, the W3C, and [you name it standards body here] keep giving us lame excuses instead of real options. And until then we are left with 80% complete excuses for using non-standard web fonts – sIFR, Cufon, and I’m sure TypeKit will not be the last.

Nov 3 2009

Desktop Application Style (Full Page Height) Fluid CSS Layout


For those of you who just want the source code, I’ll cut right to the chase. View the demo.

Now for the explanation.

For a recent project, the design spec dictated a fluid layout. Normally, this would be no problem, however, in this scenario there was a footer that always needed to be pinned to the bottom of the page content did not extend very far.

Rather than pinning the footer to the bottom of the page absolutely, I wanted to footer to scroll with the content when the content was long enough to create browser scrollbars. Rather than create JavaScript to position things onResize or scroll, I opted to create a 100% CSS/XHTML layout that accomplished exactly what I wanted.

Although the outcome is not as lean as I would like, but in the end it gets the job done well. What more can I really ask for?

Nov 3 2007

Semantic Headers and Menus (CSS of Course)


UPDATE: I’ve since rethought the implications of this post and I wanted to add that using h1 as the company name is the right choice is certain scenarios. I simply wished to provide an alternate method.

First it has been a very long time since my last post. My excuse is that I moved…and I’ve been a bit lazy. I felt the need to address a topic that seems to have been brought up to me several times over past couple weeks: CSS site navigation.

When structuring and styling menus, a definition list (dl) should be used for the site title and navigation.

The first roadblock some have with this method is that they feel the h1 tag must be used for the site title. However, using the h1 for the site title (or company name in many cases) is redundant. Your h1 (although many web builders view it improperly as a semantic whore and over use it), has great value in SEO. Because the h1 is suppossedly the most important content on a specific page, why would one waste it something like Widgets, Inc. when it could be used for maybe a content rich headline: Widgets Inc Provides Solutions for All Widgets Manufacturers. I thought the following experience was very valuable

As I observed a blind web user navigate through a few pages, he reported that hearing the h1 content on top of the page was boring and redundant for him. Because his screen reader read the content of the title element first, the title element served as the actual title of the document for him, and the h1—which merely repeated the content of the title element—was useless.

ALA – October 09, 2006 – Working with Others: Accessibility and User Research”

If a blind human and his screen reading software sees the h1 used as the site title as redundant, I wonder how it impacts how a search engines screen reader views your site’s content. Clearly, using the dt instead of the h1 for the site title is not a bad thing whatsoever.

Secondly, if you look at the meaning of a definition list you will see that it fits perfectly with the notion that you are defining your site and there direct relationship between the items (navigation). And to reiterate the advantage of not using h1 for your site name, the site navigation is now minimized along with the site name – since both are redundant and not content rich.

Lastly, stlyling your header is now a breeze. And your html structure won’t give you indigestion due to enclosing your site name, navigation, and possibly one other element (perhaps search) in a wrapping div.

Here is the markup for your reference (or view a mockup page). Using this method, you can easily create dropdown menus by nesting another unordered list (ul) inside of the list item (after the anchor tag).

<dl class="sitedefinition">
	<dt><a href="/">Company Name, LLC</a></dt>
			<li><a href="/company/">Company</a></li>
			<li><a href="/solutions/">Solutions</a></li>
			<li><a href="/strategy/">Strategy</a></li>
			<li><a href="/clients/">Clients</a></li>
			<li><a href="/partners/">Partners</a></li>
			<li><a href="/contact/">Contact</a></li>
			<li><a href="/">Home</a></li>

Sep 27 2007

Transparent PNGs in Every Browser


If you don’t want to use JavaScript or create a 24-bit and an 8-bit PNG in order to accommodate all browsers (mainly IE 5.5 – 6), you can use Microsoft’s handy Dx Attribute as filter in your CSS.

The drawback is that you have to create a separate style sheet for browsers greater than IE 5.5 and less than IE 7.

For example, if you need to use a transparency for a site’s logo, you may do something like:

<style type="text/css">
	background: url(img/button.png) no-repeat center center;
	height: 126px;
	width: 190px;

.logo a
	display: block;
	overflow: hidden;
	/*setting a width breaks link area for PC IE 5*/ ;   width/**/: 190px; /*\*//*/   width: 190px;   /**/ ;
	height: 126px;
	text-indent: -90000px;
.logo a:hover
	background-color: transparent;

<!--[if gte IE 5.5]>< ![if lt IE 7]>
<style type="text/css">
	background-image: url();
.logo a
	filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src=\'img/button.png\',sizingMethod=\'image\');
< ![endif]>< ![endif]-->

MSDN has a library of some of the possibilities (not new by any means), but helpful nonetheless.

Jun 20 2007