The web has been alive with discussion on web fonts after yesterday’s announcement of the Google Font API. I wrote about it myself yesterday and here is just a quick sample of some of the more interesting articles and discussions:

• Real Fonts and Rendering: The New Elephant in the Room – Jeffery Zeldman, 24 Ways
• Google getting into the Web Fonts game? – Typophile Discussion
• Details on the new Google Webfont API – Paul Irish
• @font-face rendering flow chart – Typophile Discussion

Yesterday I commented on the legibility of the fonts in Google’s Font Directory on Windows with ClearType turned on. After seeing Miha’s awesome  font rendering chart, I can see that my run down of Windows font rendering is only partially correct: Windows XP on default renders in “standard” mode which allows for a limited anti-aliasing smoothing but only at large font sizes or for fonts with proper Windows hinting—unless you are using IE6 and then no anti-aliasing occurs and it’s pixels, pixels, pixels.

As Zeldman points out there are more issues between browsers as well, with each browser handling font hinting a little differently, but that’s a mess I’m not about to get into. What I will do is expand my review of Windows font rendering to cover what it looks link with standard mode and no anti-aliasing. Also for your convince, I’ve added screenshots showing what it looks like with each mode (each font name links to it’s corresponding screenshot):

Windows ClearType

Vista, Windows 7, Windows XP with IE7/8, XP with ClearType turned on

Windows Standard Mode

Windows XP default with Firefox or Chrome

Windows No Anti-Aliasing

Windows XP default with IE6

Again I didn’t bother creating a list for Mac. If you are working on Windows you can use Safari to see what the rendering will look like on a Mac. Macs render type in a more consistent manner: as it decreases in size at worst it becomes a little more anemic and fuzzy. In the main, if your type is legible on Windows it is legible on a Mac.

Conclusion

Now looking at all these Windows rendering styles you can see how varying typeface legibility is:  some fonts behave well across all rendering like Droid and others preform only good with one type of rendering like Inconsolata, which looks good in standard mode but terrible in ClearType and with font smoothing off.

The Droid Family is the only font in this set that I would use for body text. All others are only suitable for headers or display text. And I would avoid using Inconsolata, Tangerine, Josefin, and Cardo except at really large display sizes (36px or larger).

Oh what a happy day to be a Web Developer! Google has released their Google Font API and the Google Font Directory with a number of Open Source Fonts. Also released in cooperation with TypeKit is the WebFont Loader which helps the FOUT (Flash of Unstyled Content) which is an issue with how Firefox handles downloaded fonts ( for more on FOUT and why WebLoader is a good thing see Paul Irish’s Details on the New Google WebFont API).

All this is great as it make it a snap to use open source fonts, either the one’s Google hosts (fast download! easy!) or you use WebFont Loader to make it simple to add other Open Source Fonts such as some of the great ones offered by The League of Movable Type. If there are licensed fonts you want to use, I recommend looking into TypeKit‘s services.

CrossPlatform Rendering Issues in a NutShell

So now that the issue of web fonts is more or less solved, the next big issue is cross-platform font rendering. The best way to sum up the difference :

Mac: the goal of font rendering is to preserve the design of the typeface as much as possible, even at the cost of a little bit of blurriness.

Windows ClearType (Vista,Windows 7, anyone using IE7/8, and XP users smart enough to turn on ClearType): the shape of each letter should be hammered into pixel boundaries to prevent blur and improve readability, even at the cost of not being true to the typeface. It is up to the font designers to build ClearType hinting into the font—without it the font may become illegible at small sizes.

Windows no anti-aliasing (XP default): pixels, pixels, pixels.

much of the above was paraphrased from a great post by Paul Irish: Font Rendering: Respecting The Pixel Grid

In practice this means that Windows users tend to think type on a Mac looks blurry and Mac users think that type on Windows looks jagged and crappy. Also, and more important is that a font needs to be hinted for Windows ClearType renderer or else at sizes under 20px it becomes ugly and often illegible at smaller sizes.

For a more detailed breakdown of how fonts are rendered check out this awesome font rendering chart by Miha.

What does this mean for the typefaces in the Google Font Directory?

So if you are a Mac user without a Windows box around you’ll mostly want to know which fonts are ugly/illegible at small sizes. I’ve taken a brief look at the fonts Google offers on my Windows PC here at work and came up with the following list. Note that some of these typefaces are meant as display only so they shouldn’t be used small anyway:

UPDATE: for a more complete chart with screenshots including Windows Standard Mode and no anti-aliasing check out Comparing Open Source Fonts – Part 2

Open Source Fonts Appearance With Windows ClearType

Open Source Fonts Appearance With a Mac

You’ll notice that I haven’t compiled a table like I did for Windows. That’s because Mac font rendering stays true to the font; thus, you can assume that display type fonts look bad at small sizes and fonts made for body text are good down to at least 12px. Also if you are on a Windows box you can easily see what it looks like on a Mac:  Download Safari and turn on it’s font smoothing (Preferences > Appearance > Font Smoothing > Light or Medium) which makes the font rendering behave (mostly) like a Mac.

*Inconsolata is a good example of a font not hinted for ClearType which looks ugly on Windows below 24px and becomes illegible at 14px; however, on a Mac it looks good even at 11px.

Gruber posted today on Daring Fireball. That the The New York Times Skimmer prototype is still available. It’s rare fascinating look at the the process that likely went through to in development of this new site:

• The New York Times Skimmer (launch version)
• The New York Times Skimmer (prototype version)

Who knows how long the prototype will remain up so go now. I’ve also added screenshots below in case the prototype goes away.

Prototype - home page

Final Version - home page

Prototype - article

Final Version - article

First of all i gotta say that this is an excellent use of modern javascript techniques. They are using the awesome jquery framework to pull in their RSS feeds and populate the skimmer ad for the animation effects.

The two versions seem to be mostly different aesthetically. There are differences between the two javascript functions but I haven’t dug into them. The most obvious UI changes with the final version are:

• Moved the nav to the right
• Removed the dark top bar and lightened the palette as a whole
• Added raised dropshadow effect around main content area
• Use of the nyt font for headlines (using Typekit.com service)
• Altered the typography (all caps for nav, removed blue from headlines, increased line-height slightly for excerpt text)
• Addition of a byline with the journalist’s name
• Articles now load in a overlay popup with the skimmer remaining visible behind it, rather than a slidedown which covers everything except the nav.
• Home Page name changed to Top Stories

All in all it’s a excellent improvement between the prototype and the final version. They went from what was essentially a mock iTunes app to a more readable approach that focuses more on the content than the navigation.

The final design recalls more the feeling of a paper, while still maintaining the clean webified rss reader approach. I especially love the use of their typeface for the headlines and the removal of the blue link color which makes it feel less like a list of links to be clicked though immediately and more like a something that deserves to be read throughly.

Still however I do have two main critiques from a UI perspective…

First a small critique: The only way to close the popup are to use the “Back to Section” button or to hit the Esc key. Instead of this approach, they should have used a simple close button on the upper right. Also clicking on the background should close the popup as well (this is how most overlay popups work).

The biggest issue however is that clicking on an article loads iframe to load the entire page. It’s a shame really. They’ve gone through all this effort to create a clean ajax approach which makes the online version of their paper fun to use and then they ruin it by dragging the user back to their cluttered site. It would have been simple to use ajax to show only the article content in a clean easy to read manner. Maybe they did this because of advertising or maybe it was because they thought iframes would be easier to code—whatever their reason, it turns the Skimmer into nothing more than a gimmick.

I’ve been inspired… and I have a long weekend, which means that I’ve spent the last couple days buried in my laptop. My back aches, my eyes are screen burned, but nothing stops the freight train called inspiration.

I give you the new and improved CatCubed.com! Also, I’m releasing Mr. Cube the Cat as an adorable papercraft doll that you can make yourself! Like the new version of the site, he’s still in beta but he’s stable and I’m releasing him into the world anyway!

Download the Cube the Cat, papercraft PDF (version 0.6 beta).

Yep, I’ve gone and scratched that designer itch that has been bugging me for a while. I’ve decided to use CatCubed as a means to experiment with new web techniques. Besides the cute little paper Cube the Cat, the new site includes:

• HTML5 semantic structural elements – minimizing the use of divs except where appropriate. I’m still not perfectly happy with the semantic structure of the HTML. Some limitations were due to the layout particulars and the wordpress CMS. I will revisit this at a later point so that it is more in line with proper HTML5 semantics.
• Extensive use of new CSS3 styles – multiple background images, rounded corners, rgba, box shadows, etc.
• CSS built using SASS
• Simplified navigation – Got rid of the sidebar modules clutter. Also, post categories have been reorganized with a focus on the three main things I write about art, code, design.
• Coming Soon – more robust art, code, and design sections with highlights of my various projects. Mobile version of the site (it’s a image heavy site now, so I think a mobile version is in order.)

The site works best in webkit browsers (e.g., Safari, Chrome, or Internet Explorer with Chrome Frame). If you are on a gecko browser (Firefox, Camino) everything works but you are missing a few design elements due to lack of Firefox’s ability to use multiple background images (this is supposed to be added in Firefox 3.6). I have not tested the site in Opera, but Opera is decent so it should work (except for some of the CSS3 styles). I also haven’t tested in any version of Internet Explorer, and I don’t plan on it. I’ve added the HTML5  shiv so that IE will recognize the HTML5 elements, but considering the fancy things I’m doing with floats, it likely fails pretty bad.

I’ve kicked this whole thing out fairly quickly and I’m experimenting with a few things so there are likely a few issues here or there. If you are running webkit (Safari, Chrome) or gecko (Firefox) and run across any bugs let me know.

I have a few additional things I want to do to this site over the coming weeks and months. So expect to see more changes.

I’ve recently decided it was time to revamp catcubed.com. The design will be overhauled and it will be developed using new HTML5 structural elements. I’ve begun this process by researching the proper semantics and layout techniques for these new elements. The W3C HTML5 specs are vague in spots and this is all fairly new so there is some disagreement among the supposed “experts.” There are already a couple wordpress HTML5 templates out there, but they also differ in many ways.

What follows is the guidelines I’ve devised based on both the W3C HTML5 specs (I usually refer to the latest draft and then review any differences with the older last published version) and the collective opinions of the various “experts”—not all of whom I agree with. A list of reference links is included at the bottom of this article. I’m fairly new to all this too so I could be wrong about a few things so please let me know if you find any flaws in these guidelines.

[...]

Some of you may have noticed that the new SF Tweed site has launched and we have announced the next Tweed Ride!

This labor of love has taken longer than I expected ‚Äî live’s been busy ‚Äî but I’m quite happy with the results. A big thanks to Rubin Starset for buying the domain, setting up the WP install, and most of all motivating me to kick out a design and get this thing happening!

I expect to see y’all at the next Tweed Ride as we have some great things planned.