FontFriend 3.1 Loves Google Webfonts

I’ve had a number of requests to better integrate Google Webfonts into FontFriend. They keep adding all these great fonts that anyone can use for free, and should be part of a tool like FontFriend. The trouble was that they didn’t have an API, making it difficult. More on that later, because I got it working:

Just pick a font from the dropdown list

Invoke the bookmarklet as usual (it’s always up to date), and you’ll see a fancy new Google Webfonts dropdown. Pick a font and it’ll appear in the custom Font Families list. All variants (all weights, both roman & italic) are automatically pulled in.

How was I able to do this without an API? YQL to the rescue, which it turns out is awesome for tasks like this. But, after posting a teaser on Dribbble, Pablo Impallari hooked me up with the Google Webfonts teams, who will have an API for this in place soon. I debated waiting to release until then, but I’d already done the work, so why not let everyone play already?

One other little nugget: FontFriend will detect already-embedded Google Webfonts on your page and throw them into the custom fonts list automatically. See a demo of Google Webfont detection.

Finally, after tweeting about it,  I’ve had representatives from a few webfont services reach out to me about better integration once they get their APIs in place. There should be more ways to play in the future!

FontFriend 3.0 Released

I’m pleased to announce the immediate release of FontFriend 3.0, the Typekit integration edition. Invoking the bookmarklet on any Typekit-enabled page will automagically throw all the fonts in your kit into the custom families list. I’ve set up a demo page with FontFriend embedded and a big Typekit kit. uses Rosewood Fill and Chaparral

My main imagined use-case for this feature is the designer trying to test out a variety of webfonts on their page. I’d introduced custom lists in FontFriend 2.5, but they didn’t play well with Typekit, as I discovered when redesigning my personal blog. I’d hacked in a feature for my own use, but was never really happy with it.

But then I remembered that Typekit has an API.  They even have an example bookmarklet that lists every font in your site’s kit, doing most of the work for me. A couple of short weekend coding sessions later, the feature was integrated. Just activate FontFriend on a Typekit-enabled page and you’ll see the Typekit logo and your kit’s fonts in the custom list. Check out the demo page to see this in action on a page with a big Typekit kit.

But wait, there’s more! FontFriend 3.0 also populates your custom font list with every @font-face-declared font family currently active on your page. See a demo. This only applies to rules declared in stylesheets on the same domain due to cross-domain security restrictions, which means that most third party webfont services are left out in the cold.

Other 3.0 features/changes:

  • Reorganization of the modules to better suit my imagined optimum workflow
  • Font weight is now a dropdown to give you numeric access to all weights
  • All dropdowns have arrow toggles beside them for speedier changing. (I dislike the tedious “click, move mouse, click again” flow of dropdowns, so this should help.)
  • Drag and dropped @font-face fonts now get thrown in the custom font family list
  • Drag and drop now uses the asynchronous FileReader API, which should be much more performant, especially when dragging in multiple font files at once. (Thanks to Ryan Seddon for his work on FontDragr that showed me the way.)
  • The previously missing Font Style module is now included. Hello italics.
  • Big reorganization of the code. It’s still a bit squirrely, but better organization will make it easier to add (good) features in the future.

I’d love to support other webfont services, but none of them have APIs that can do what I’ve done with the Typekit API (or at least not that I’ve discovered). Other services: please let me know if/when that changes!

Web Typography Pain Points

When I launched, I said that I had some things to say about the state of CSS typographic controls. I’m making good on that threat. Things have come a long way from too-long measures of Times New Roman on a mid-gray background, but CSS still lags behind page layout software in many areas, which is only compounded by inconsistent browser implementation.

I’m going to especially focus on ::first-line and ::first-letter pseudo-elements which, to my surprise, WebKit has some massive problems with. Specifically:

  • WebKit does not accept text-transform on the ::first-line pseudo element. This embarrassing bug is almost 6 years old and means that the common typographic practice of setting the first line of a paragraph in all-caps is impossible in Safari, Chrome, and—insanely—iBooks, which uses WebKit for its ebook rendering. The closest you can get is font-variant: small-caps which would work fine if we could also use text-transform: lowercase, but we can’t.
  • WebKit also doesn’t accept a font-family rule in both the ::first-letter and ::first-line pseudo-elements. The latter is usually OK, but the former really sucks. Even worse, in both cases, a font-family rule will cause them to fall back to the system font!
  • WebKit has a bug where modifying the DOM of an element that has a ::first-letter CSS rule attached will result in a phantom first letter. See QuirksMode’s test case. (Opera does this too.)

Firefox isn’t all roses either, despite their terrific efforts in bringing long-awaited OpenType features into CSS. The main thing I noticed was that Firefox treats ::first-letter oddly style-wise. It doesn’t seem to behave as a full-fledged block-level element when setting float or display properties. It also compounds the font-size when the ::first-letter coincides with another DOM element that also sets the font-size.

Some other issues:

  • WebKit sets its pseudo-small caps (when using font-variant: small-caps) smaller than other browsers. It also seems to add some pseudo-emboldening to better compensate for the fact that they’re not true small caps.
  • Inconsistencies between browsers in conforming to the ::first-letter spec for including punctuation characters. Specifically, WebKit only seems to include punctuation that precedes the letter, not punctuation after it.

I’ve created a test page that illustrates a lot of these pain points. I also made a page that demonstrates a WebKit normalization strategy with some UA sniffing and the jQuery fancyletter plugin, which I contributed a small patch to along the way. I’d describe that strategy, but then this post would never be published. View source!

Redesign of

I just launched my redesign of my personal blog (formerly and I couldn’t be happier to finally have it live. This is a full-circle moment for me, as tweaking my blog (first on Blogger, later on WordPress) was what launched me into web development. After seeing that I could produce better code and design than most of what I was seeing on the web, I thought I’d give it a go. 3 fun and busy years later, my personal blog has sat stagnant in both content and design.

Design Philosophy

I’m a big fan of design constraints. For this project–just like my WordPress theme The Erudite—the major design constraint was “it’s all about the content.” This meant saying goodbye to all the cruft of today’s blogs: sidebars, social media sharing links, ads, and all the junk that distracts from reading the actual content. I might relegate some typical sidebar-type things to the footer (archive navigation, search) but for now I’m really enjoying the minimalism.

Type & Typography

Web design is 95% typography, and this design pushes that to 99.9%. I’ve made use of Robert Slimbach’s excel­lent Min­ion Pro for body text, while head­lines are set in Carol Twombly and Slimbach’s Myriad Pro Con­densed. Both are served by the fine folks at Typekit. I made extensive use of Tim Brown’s Modular Scale tool for all dimensions, which is why the design (hopefully) feels natural. My scale is 18px/15px, Musical Fifths.

Also worth noting is that advanced web typography is still a landmine of browser inconsistencies and outright bugs. I will be revisiting some (painful) lessons learned in a future post.

Responsive Design

Responsive design is fun. Being able to provide a single template that works on a variety of devices and at different screen widths has been the web design holy grail for years, and now we can do it. I targeted the iPad portrait view (768px wide) as the ideal view, as that’s how I enjoy reading the most these days. Browsers that don’t understand media queries will show this style. I adapt the style to varying degrees for widths of < 1024px (wider screens), 431–649px (iPhone landscape), and < 431px (iPhone portrait). I think it turned out pretty well. My focus on content made this process relatively straightforward.

Post Counts

The only non-standard design element I included was a post count. This is an attempt to game myself into posting more often. I’ve set myself the goal of reaching 500 posts by the end of the year, and I now have a constant visual reminder of my progress. We’ll see how successful this self-gamification design element is. Anyone who’d like to integrate this into their own WordPress templates can grab the code.

A Work in Progress

There’s still more to do. Archives and search need to be designed and exposed. I want a better experience for the home page; something to describe myself and the site better to new visitors. If you have any suggestions/critiques, please sound off in the comments below!

The Definitive @font-face Syntax

UPDATE: The syntax has already been improved to favour IE9 loading WOFF instead of EOT, thanks to some sleuthing by the CSS Ninja.
UPDATE 2: The syntax now uses a ? instead of a # because local IE requests choked on the #.

Ethan Dunham of Font Squirrel and Fontspring fame has just released the definitive @font-face syntax. I’ve been hyping it up on my Twitter account, but this is too good to restrict to my followers there. The new syntax is clean, beautiful, and simple. It looks like:

@font-face {
   font-family: 'MyFontFamily';
   src: url('myfont-webfont.eot?') format('eot'),
        url('myfont-webfont.woff') format('woff'),
        url('myfont-webfont.ttf')  format('truetype'),
        url('myfont-webfont.svg#svgFontName') format('svg');

Here’s the magic he found:

The hack trick that makes this work is the ‘?’ following the EOT filename. Seriously.

Just awesome. Great work Ethan!