Color Garden

Color Garden is a free theme released on Museum Themes under the GPLv3.  This theme is jam-packed with features, from WordPress 3.0 functionality to Twitter integration.  Color Garden uses WP3.0′s custom header option, and comes with 4 unique headers that accent the 4 color palette options available on the theme options page.  We’ve also built in custom menus, custom backgrounds, and post thumbnails, hitting all the bases for cutting-edge WordPress functionality.  If you use Twitter, we’ve got you covered there, too, integrating Twitter’s new Tweet button into our existing social sharing block on single post pages and providing options to display your latest tweets in the sidebar or the footer.  The footer and sidebar are completely widgetized, and the footer has three distinct columns to add widgets.  If that wasn’t enough, we’ve embedded a custom typeface in the header using CSS font-face.  Each color palette has its own unique stylesheet, so you can easily use this theme as a framework or build child themes (or skins) for it.

View Demo | Download Color Garden

2.7 MB
downloaded 79 times

You might also be interested in these:

  1. Simple Gray
  2. erin’s sketchbook
  3. Baby SweetTooth

Ex Libris

Ex Libris was designed for writers and typophiles.  Lacking fancy graphical bells and whistles, we focussed our attention, instead, on making your content readable with full typographic control.  Ex Libris features a unique approach to choosing the typography for your site.  Rather than relying on the tired basic web fonts, we’ve embedded the gorgeous free fonts from font foundry exljbris, giving you freedom to style your site with access to full font families and unique typefaces, while maintaining a consistent visual style.  We’ve also built the theme with a unique, optional home page layout (Magazine Style, pictured above), and kept an uncluttered approach to page layouts.

If you’re a writer, if you love minimalism, clean design and unique typography, Ex Libris was made for you.  Literally.

View Demo | Buy Ex Libris — $60

You might also be interested in these:

  1. AP Museum zine

Simple Gray

Simple Gray is a minimalist WordPress theme we did a couple years ago.  Having not touched it once in over a year, with the launch of Museum Themes, we figured it was time to revisit it.  We’ll be revamping all our old free themes and officially releasing some of the ones we never got around to.  Added features to Simple Gray are Twitter @anywhere hovercards, WordPress 3.0 menus, installation notes, Google’s Droid Sans web font, and some nice css3 shadows for browsers that can see them.

View Demo

Download Simple Gray 137.5 kB
downloaded 49 times

thinking about redesign…again…

So now that Museum Themes is up, WordPress 3.0 is out, and web fonts have made huge strides in browser-integration, I’m thinking about redesigning  Again.

discount browncoatOkay, yes, I am fully frakking aware that I redesign my site more frequently than a hooker gets checked for STDs, and even the Browncoat theme lasted longer than the current design.  But here’s the thing with both of these designs: both of them were just products of trends or ideas I was really into at the time.  This theme is sort of a failed experiment at making WordPress more like Facebook, except that the problem with that is that — from a content standpoint, Facebook sucks ass.  Who the fuck wants to read someone’s Facebook wall, I mean honestly?  I did this, I unlocked that, I’m listening to this stuff, help me with my Mafia, I need 4 nails, this is a cool article.  Twitter might be self-indulgent, but at least there’s some people out there (and I try to be one of them) that provides valuable and/or interesting links, direct interaction, possibly some witty or snarky commentary.  So, yeah, an endless stream of the stuff I happen to be doing right this second?  Probably best left as an interesting idea and that’s that.  There’s a reason why you don’t see the word “lifestream” around nearly so much now as you did a year or 6 months ago.

With Museum, I was building things into the themes that I thought was cool, like @font-face calls.’s current theme (called ::metal:: in case you didn’t know) still relies on sIFR — an old font-rendering workaround that converts text into a Flash swf and displays that.  The problem is — in case you didn’t notice — sIFR can be slow as all hell, and everytime I load this site that pisses me off.  Especially when I know there’s a better way of doing it (namely, calling the freaking font).

There’s still stuff I like about ::metal::, don’t get me wrong, and I’ll include that stuff in whatever incarnation the design takes.  It’s just sort of lame lusting after WordPress themes I designed for other people and being frustrated with my own blog design.  And there’s so many things that WP 2.9.2 – 3.0 added that I’ve been dying to use instead of, or in addition to the things I’m doing now that it just drives me insane.

The problem, of course, is that my mind, inevitably, veers toward the function more than the form — which was the case with ::metal::.  I have no real idea what I want the new theme to look like (other than something else), I just know what I want it to act like.  At least with Browncoat I had an idea and I liked it, it just became limiting when what I wanted to do with the site broadened.  I think the main problem with where I went with the design for ::metal:: was that I was still thinking too much in-the-box.  I wasn’t looking at art, I was looking at BlueprintCSS and grid-based design, and that’s what I did.  I think this time around, I’m going to have to look at some frickin’ art.

Like this shiznit.

Jumping on the webfont bandwagon

Webfonts are literally changing the face of web design (no pun intended). Even just between the time I wrote my last post on @font-face and now, there have been numerous additions to best practices and available services for invoking new, creative typefaces in your web pages.  It’s dizzying getting started because there’s just so much out there and new methods of calling fonts are cropping up all the time.  In this article, I talk about what the web font formats are, where to get them and how to use them.

What the options are

TrueType/OpenType – I’m not going to go into the difference between TrueType and OpenType in this post.  The two things exist and they are more or less the same and are typically the most common font types.  The important thing about these formats is copyright; what’s linked when you use either OpenType or TrueType fonts in your stylesheet or code is the original, unmodified font (or a variation of it) which gets downloaded as an element of the web page (just like any other element of the page like graphics or Flash).  Therefore, if you’re using TTF or OTF fonts in your code you need to be sure that the font you are using has an open license that allows for public usage.  If you don’t, you are potentially violating the font creator’s copyright and could get in a lot of trouble.

EOT – The Embedded OpenType format was developed by Microsoft in 1997 with the release of Internet Explorer 4.  What makes EOTs geared for the web is that they can only be viewed in a web browser (and, being a proprietary format developed by Microsoft, only one web browser is able to support them, that being IE).  It shouldn’t be a surprise, then, to know that Internet Explorer only supports EOTs for web fonts (thus far).

WOFFWeb Open Font Format was developed by Jonathan Kew from Mozilla, Tal Leming from Type Supply and Erik van Blokland at LettError and was first supported by Mozilla Firefox.  Like EOTs, WOFF fonts are only viewable in a browser and have the added benefit of additional compression (capable of decreasing the size of the font by up to 40%) and is able to contain additional metadata, such as the font creator.  WOFF is a favored format by the W3C as the standardized web font format and is planned for support in Internet Explorer 9 and a forthcoming version of Google Chrome.

Cufón – Cufón was designed to be an alternative to sIFR.  While not a font, per se, it shares a lot of similarities with standard web font embedding and may also violate existing copyrights on proprietary typefaces.  Cufón is a javascript-based method that converts the font into VML (for Internet Explorer) or SVG (for everything else) to render the characters as vector graphics.  Like standard web font embedding, an external file is required (in this case a generated font file read by the javascript) which is downloaded as an element on the page.  One substantial benefit of Cufón is that the rendered fonts are often much smoother than can be achieved by embedding the actual font itself.

Where to get the fonts

You may be looking at the list of different font types and wondering how you convert your fonts into one of those than can be embedded into a page.  Don’t worry, it looks much harder than it is…

For standard TTF and OTF fonts, there are numerous places to download free fonts.  However, not all fonts that are “free” to use are actually “free” to embed on your website.  DaFont does a good job of distinguishing free, free for personal use and commercial, as does FontSquirrel.  There are also open font movements like the League of Movable Type and the Open Font Library which have repositories of free fonts that are safe to use on your site.

EOTs used to require an antiquated Microsoft-developed tool for converting fonts to EOT format, but the renewed interest in the format has led to the development of a couple of alternate methods.  For people comfortable working from a commandline, there’s TTF2EOT.  This simple Windows/*nix-based tool adds a simple commandline interface to convert a selected font to EOT.  For the less geeky, there’s EOTFast, however, as of this writing, it is still under development.

Similarly, WOFFs have a commandline tool called sfnt2woff which converts TTF or OTF font files to WOFF.

For Cufón, you pretty much have to use the web-based generator on Cufón’s home page.  While it gives almost complete control over the end result, the plethora of options can be a little overwhelming.

Luckily, the best and easiest place to get the fonts or have them converted is from the @font-face Generator at FontSquirrel.  FontSquirrel’s @font-face Generator comes in an Easy and Expert mode, so you can choose whether to let the generator pick the best options for you or to have more full control over the options.  Better still, it is able to generate TTF, OTF, EOT, WOFF as well as Cufón files, in addition to the actual CSS and markup needed to call the font (excluding Cufón which — presumably because it’s so much different from standard @font-face embeds in terms of how to integrate it into your site — you’re on your own for the code).  After you accept the agreement that the fonts you are using should be free to use, you just upload your source TTF or OTF and get a zip file containing everything you need to embed your font.

How to use them

If you used FontSquirrel’s Generator,  you can pretty much use what it spits out verbatim.  Even so, it helps to know what you’re doing and why, and there’s a few tricks that might help along the way…

First off, the code.  This is Paul Irish’s Bulletproof: Smiley variation of the @font-face declaration, and is edging to be the standard.  You can read his post about why it’s the best option.  For my part, I defer to the experts who have spent much more time than I have researching all the variables.  If you downloaded your kit from FontSquirrel, you’ll already be using the smiley declaration.

  1. @font-face {
  2. font-family: 'Graublau Web';
  3. src: url('GraublauWeb.eot');
  4. src: local('☺'),
  5. url('GraublauWeb.otf') format('opentype');
  6. }

Simply replace the filename above with the path to the font and set the font-family name to what you’ll call it later.  It should be noted that Firefox has problems with paths that aren’t relative (e.g. full url paths) — this is a security precaution to prevent people from injecting malicious code into their site from off-site.  In most cases, this isn’t an issue, but it can pose a challenge if, for example, you were trying to use @font-face on a site with no local storage (like a BlogSpot blog) and were using some kind of off-site dump to host your files.

So that declares what that font is.  When you actually want to use it, you just add the family name to your font-family the way you would normally, so something like this:

  1. h1 {font-family: 'Graublau Web', 'Times New Roman', Times, serif;}

You’ll also, of course, need to have uploaded the font to the server and make sure your source url points to the right place, but other than that, it’s pretty simple.  So what of these special considerations and tricks I mentioned?  Well, as usual, the first problem involves Internet Explorer.

If you’ve played with @font-face declarations at all, you may have noticed that your font looks great in Firefox, spectacular in Chrome and Safari, and like absolute crap in IE.  Ironically, this is because of ClearType — you know, that service that was introduced in WindowsXP that was designed to introduce font smoothing.  In IE7 and higher, ClearType is running within the browser, which in most cases is fine except when it comes to custom fonts.  In that case, it’s evidently trying to do a task that’s not required of it, and ends up hacking away at the edges which is what gives you the horrible jaggy appearance.  (This is one case in which, actually, IE6 is less broken then its successors.  Too bad it will be nigh impossible to find a machine that uses IE6 anymore.)  The fix, then, is to turn off ClearType, which, conveniently, you can do using Microsoft’s browser filters.  In the above h1, you would change it to look like this:

  1. h1 {font-family: 'Graublau Web', 'Times New Roman', Times, serif;
  2. filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src=images/headers/hIEfix.png,sizingMethod=crop);zoom:1;}

I won’t go into detail about the what’s and why’s of this.  It’s a hack (as per usual) that exploits the fact that IE’s filters don’t use ClearType functionality to prevent possible other problems.  You can read more about the hack and download the source files at (including the 1×1 px hIEfix.png required for this to work).

The second problem has been dubbed FOUT (Flash Of Unstyled Text).  In WebKit (Safari & Chrome), text that is styled in custom fonts doesn’t actually load until the font loads.  Other browsers, most notably Firefox and Opera, load the fallback or a default font first, then the custom font when it downloads.  This is FOUT, and can be jarring to the user.  There’s a couple of best practices here and then some ideas on how to fight the FOUT.

FOUT best practices:

  • Keep your fonts small.  Just like images, the smaller the font file size is, the faster it will load, and the less time the browser will take downloading it.  Tools like FontSquirrel’s font generator can actually reduce the size of the font, and if WOFFs become standardized, that will help out as well since they’re compressed.
  • Load your fonts first.  Most browsers work on a first come-first served basis for all elements, so putting your fonts right up at the top will help get them loaded first.  If you’ve got your font declarations in your normal css file, load that first.  If they are in a separate css file (which isn’t a bad idea), load that.  A rule of thumb is to load your font right underneath the according to a presentation given by the guys at Unmatched Style, it decreases the load time for the font.
  • Subset fonts.  Fonts often come with hundreds of different characters, including special characters, which you may or may not be using.  Off the top of my head, I can think of several fonts that have the same characters for upper- or lower case letters.  If you don’t need the extra characters, you can just not include them in your font and this will make the font size smaller.  This is another thing you can do with the FontSquirrel generator.

If all else fails and you still need some help with the FOUT issue, there’s a couple of hacks you can try.  Like the “smiley” @font-face declaration, these come from Mr. Paul Irish who writes about fighting FOUT.

The first thing you can do is preload your fonts.  This is similar to the method of preloading images that display on a hover event where you use a display: none; or a visibility: hidden; or push it all the way off the screen somewhere in, like, left: -999em;.  Let’s say you’ve got two fonts you’re using on your site:

  1. @font-face {
  2. font-family: 'ChunkFive Regular';
  3. src: local('ChunkFive Regular'), url('fonts/Chunkfive.otf') format('opentype');
  4. }
  6. @font-face {
  7. font-family: 'League Gothic';
  8. src: local('league gothic'), url('fonts/LeagueGothic.otf') format('opentype');
  9. }

We’ll create some CSS styles to call those like this:

  1. .chunk { font-family:'ChunkFive Regular'}
  2. .league { font-family:'League Gothic'}
  3. .allfonts { font-family: 'ChunkFive Regular', 'League Gothic'; }

Now, in the actual body of the page, we’ll preload those fonts:

  1. <!– preloads both fonts in gecko and opera, webkit only gets the first –>
  2. <b class="allfonts" style="position:absolute; visibility:hidden">download please</b>
  4. <!– preloads all the fonts in the fontstack in gecko, opera, and webkit –>
  5. <b class="chunk" style="position:absolute; visibility:hidden">download please</b>
  6. <b class="league" style="position:absolute; visibility:hidden">download please</b>

Personally, I think the .allfonts class is overkill if you’re calling both of them individually anyway, especially given that that’s targeting WebKit and WebKit isn’t our problem.  IE will download the fonts when they are declared, so this doesn’t affect IE at all.  Also, one thing you should be aware of if you decide to use this method is that it won’t validate, if that matters to you.

The other option is to target Firefox directly with this javascript which asks Firefox to act like WebKit, e.g. don’t load the text until the font has loaded.  For really slow-loading pages, there’s a 3-second fallback so people aren’t waiting forever for pages that take a really long time to load.  To do that, you will put this in your <head>:

  1. (function(){
  2. // if firefox 3.5+, hide content till load (or 3 seconds) to prevent FOUT
  3. var d = document, e = d.documentElement, s = d.createElement('style');
  4. if ( === ''){ // gecko 1.9.1 inference
  5. s.textContent = 'body{visibility:hidden}';
  6. e.firstChild.appendChild(s);
  7. function f(){ s.parentNode &amp;&amp; s.parentNode.removeChild(s); }
  8. addEventListener('load',f,false);
  9. setTimeout(f,3000);
  10. }
  11. })();

This isn’t going to absolutely fix the problem either.  All of these are just ways to try to avoid the FOUT issue and none of them are foolproof, but they can help.

Alternate methods

There are some other methods for calling custom fonts.  One that I mentioned at the beginning is Cufón.  With Cufón, you must have, or link to, the source javascript, so the first part is to either their generator (or FontSquirrel’s generator).  When you have both files, you’ll call them in  your like this:

  1. <script src="cufon-yui.js" type="text/javascript"></script>
  2. <script src="Vegur_300.font.js" type="text/javascript"></script>
  3. <script type="text/javascript">
  4. Cufon.replace('h1');
  5. </script>

As you can probably guess, Cufón works by substituting its font in a given class (h1 in the above example).  If you want to use multiple fonts, you can do that with this:

  1. <script src="cufon-yui.js" type="text/javascript"></script>
  2. <script src="Vegur_300.font.js" type="text/javascript"></script>
  3. <script src="Myriad_Pro_400.font.js" type="text/javascript"></script>
  4. <script type="text/javascript">
  5. Cufon.replace('h1', { fontFamily: 'Vegur' });
  6. Cufon.replace('h2', { fontFamily: 'Myriad Pro' });
  7. </script>

It’s a little clumsy compared to @font-face and some of the other alternate methods, but if you’ve used sIFR (and by used, I mean embedded by hand, not just used a WordPress plugin), it’s probably pretty familiar.

Typekit has a bit of a roundabout method mostly to maintain control over commercial fonts and to make sure that only the font that was selected from the site and registered to you for use on the site you’ve registered with Typekit will display.  For the most part, though, it’s just two lines of javascript and a CSS class you set on the site; so, similar to what we’ve been doing already.  There are a few other companies, like Extensis with WebINK, that are jumping into the webfont market that handle it similarly.  In any case where you’re using a service, you’ll more than likely be using a javascript to contact the service and retrieve the font.

As of May 19, 2010, Google has launched their own webfont service and, for what it’s worth, it seems really promising so far.  They are using open and Creative Commons-licensed fonts and have an easy to use font directory (with only a handful of fonts right now — hopefully this will grow as time goes on).  When you find the font you want to use, you just need to click “Get the code” and voila there’s your source, which, in this case, is an externally hosted stylesheet like this:

  1. <link href='' rel='stylesheet' type='text/css'>

Then you just need to call the font normally in your CSS.

  1. h1 { font-family: 'Droid Sans', arial, sans-serif; }

The Google Webfont API also includes a webfont loader.  I haven’t played with this yet, but it appears to be similar to the preloader I mentioned earlier.  One interesting point to the webfont loader is that it’s written to allow fonts that are being loaded from other sources, not just Google.  It was co-written with Typekit, so of course Typekit can be called with the loader as well, like this:

  1. <script type="text/javascript" src="">
  2. </script>
  3. <script type="text/javascript">
  4. WebFont.load({
  5. google: {
  6. families: [ 'Tangerine', 'Cantarell' ]
  7. },
  8. typekit: 'myKitId'
  9. });
  10. </script>
  11. <style type="text/css">
  12. .wf-inactive p {
  13. font-family: serif
  14. }
  15. .wf-active p {
  16. font-family: 'Tangerine', serif
  17. }
  18. .wf-inactive h1 {
  19. font-family: serif;
  20. font-size: 16px
  21. }
  22. .wf-active h1 {
  23. font-family: 'Cantarell', serif;
  24. font-size: 16px
  25. }
  26. </style>

Confused by all the options?  Here’s a comparison of FontSquirrel-generated fonts vs. Typekit vs. Google Webfonts.  This gives you a bit of an idea of how each font is rendered, and it’s all HTML/CSS so you can check this page in multiple browsers to compare browser compatibility.

And that’s pretty much it.  Before going, I should mention that FontSquirrel also has premade kits for a variety of different @font-face embeddable fonts, so it’s a good idea to see if the font you’re looking for already has a kit.  Also, some browsers don’t automatically bold or italicize some custom fonts so, like in print design, you need to declare the bold or italic variation separately.  There’s more discussion on that, if you’re interested, at the end of the Unmatched Style @font-face presentation.  Thanks for reading this far — I tried to make this as comprehensive a post as I could so if you know of any tips, tricks, hacks or other sources, let me know in the comments!


2e6c0a0ecb51c9d67263485a1713294d Jumping on the webfont bandwagonChris Reynolds is one half of Arcane Palette. He has a personal blog, jazzsequence, where he writes about music, technology and social media and shares links, videos, and posts various personal music and writing projects.