lowest-common-denominator.com

You can see Typekit in action on Jeffrey Veen’s website (I assume this is the proposed implementation of Typekit). [Update: 3rd June 2009, It looks like Jeffrey is no longer using Typekit on his website. No previews for you.]

A remote javascript file is linked by the website owner that includes a copy of the jquery framework, and a Typekit class that writes in the dynamic CSS and javascript files specific to that website.

From what I can make out, .otf fonts are embedded in a dynamically injected CSS file using a base64 encoded data url. Although this increases the size of the file compared to its binary equivalent, it can benefit from server compression like gzip. I’m not sure if this is an attempt at obsfucation, or used for convenience, but it’s trivially easy to obtain a fully functioning .otf file. Older IE browsers (IE7 and below) are Internet Explorer (including IE8) is served a fallback to an EOT file.

Because Typekit injects cross-site scripts, you the web developer have to be able to trust the security of their service as much as you would trust your own server setup. Potentially, if they are compromised, any file they inject into your page could also compromise your visitors.

In common with other font replacement techniques, Typekit relies on Javascript and (in Safari at least, I didn’t test in other browsers) suffers from Flash of Unstyled Content.

It seems to me that Typekit is a service where users can subscribe through a single portal to manage the embedding of @font-face compatible fonts (falling back to EOT where necessary) from participating foundries (who?). That’s nice, as far as it goes, but the hyperbole about changing the face of the web is getting way out of hand. The new thing here isn’t Typekit, but the tipping point that’s been reached of browsers that support @font-face.

The Online Photographer has switched to partial text feeds. This is a shame, and is likely to silently hurt the site’s feed-consuming readership, and thus its ad-revenue.

Using a feed reader helps to manage a lot of content with limited time resource. Short entries, like curated links, can often be dealt with there and then in the feed reader. Longer pieces will get a click through so they can be enjoyed in context. However, unless an entry can be seen in its entirety it can’t ever be considered worth my time. No excerpt or teaser can substitute for the actual content when making this assessment.

The feed reader is my triage station. With limited resources I need to assess an article’s fitness quickly and decisively. Casualties ceaselessly flood in, presenting themselves with a variety of crippling conditions seeking my attention. A partial entry feed is like having a patient stuck down a mine shaft with their guts hanging out; hard to get access to and probably not worth the effort.

John Gruber shared a code snippet that converts strings to Title Case. It’s actually more clever than it sounds, taking into account the need to keep a collection of small words uncapitalised, and correctly handling punctuation issues.

Here’s a version for Movable Type that can be used to automatically convert entry titles to title case. It is essentially a wrapper for John’s script that adds some functionality to deal with html entities (so it should play nice with Smarty Pants and Widon’t).

Download

Title Case for Movable Type v1.1 (2008-05-23)

Installation

Unzip the file and place TitleCase.pl in the plugins directory of your Movable Type installation.

Usage

For titles, add the global filter titlecase="1" to your entry title tags: