One theme to rule them all

If you follow us on Twitter or Facebook, you may already know that we recently released our first theme to the official WordPress repository.  It’s called Museum Core.

Museum Core is the product of over a year of development.  A solid foundation built on responsive design, HTML5 and CSS3, with a theme options page that is secure and flexible.  It also supports localization into any language you want.  In less than a month, it’s already been downloaded more than 3,000 times.

Core marks the beginning of our shift in scope for Museum Themes.  Rather than maintaining dozens of different themes independently, all themes, past and future, will become child themes of Core.  Additionally, we’ll be using Core to build WordPress versions of our most popular and favorite Blogger templates — we’ve already released WordPress versions of Grandma’s Hat Box and dear Audrey, and more are on the way.  Soon all our themes will be driven by the powerful Core framework, while maintaining the same level of customization options they currently offer.

Exciting things are coming in the next few months for Museum Themes.  For now, here’s our promo video for Core and some more information about what it supports.

Here’s a list of some of the features in Museum Core:

  • customizable sidebar (left or right)
  • full posts or excerpts on main blog page and archive pages (excerpts support post thumbnails)
  • customizable footer text (no hard-coded author credit)
  • five typeface options for 3 different locations (headings, body and alternate) with an eye for international language support
  • customizable link colors via an easy-to-use color-picker
  • custom favicon
  • optional support for Twitter hovercards
  • responsive design that supports smaller screens and mobile
  • supports all WordPress post formats with different layouts optimized for each
  • internationalization support.  Complete Polish translation in 1.0.9 courtesy of anemoone.


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.

How I broke a javascript gallery script to make a Flash-like slideshow

This is a story about a site redesign.  The site was for the mother of a client we’ve worked with on other projects.  It was a kind of site we don’t normally do, but we took the gig because it was a referral and someone we know and like working with.  The original site was built in WordPress, and our job would be to fix it up, make it more SEO-friendly and just generally take what they did and make it better.

When I got access to the WordPress backend and found that, rather than building a new theme, the previous designers just added styles to the WordPress Default theme, I figured just how right I was to just take what they did and make it better.  They also controlled the layout via tables and built no custom page templates, all of which told me that they didn’t understand the possibilities and/or were not very skilled WordPress designers or they were just really lazy.

One of the first things I noticed on the site was that there was a lot of graphics that were mostly text.  Search engines can’t read images, so this text – much of it was the sort of keywords that would be valuable for search engines to crawl – was useless (at least from a search engine standpoint).  In addition, said text was, in many cases, jaggy and ugly.  My question: why bother making text into an image if it doesn’t look smooth and clean?  Either use a unique font you can’t get with available web fonts and make it look nice, or just use regular text.  So the first step was taking several graphics like this and removing all the text, and then adding the text to the code and styling it with CSS.  To get a more unique and attractive look (i.e. to make it look more visual and like the graphic it was replacing) I added subtle text-shadows and styled the font using @font-face.

There was also one of those Flash slideshows as a major feature of the home page.  You know, the Flash slideshows with an image and some text.  None of it is interactive; you can’t click on anything to link to a page or anything, and those images, too, had text buried in them that would be relevant for search engines, using the sorts of phrases that I would expect users to actually use in search queries.   My next question: why use a Flash slideshow when you could have the exact same effect, and make the text searchable, by using available javascript-based technologies like AJAX?  The next task, then, was to find some jQuery slideshow script similar to Dynamic Content Gallery or Featured Content Gallery.  In fact, since it was WordPress, I considered building one of those into the theme and using a redirect to point them all to the same page, but ultimately, this would be a bit of a lame hack and I found a better solution.

First, I found a simple jQuery image slide show that I could customize the code for (demo here).  Like Featured/Dynamic Content Gallery and a multitude of other slideshows like them, there was a caption that would rise up from the bottom and then slide back down when the image transitioned.  But up and down didn’t really work for the layout I was using.  I really needed it to either be there all the time (like it would be if it were a static image in a Flash slideshow) or come in from the right side.  Here’s the relevant javascript code:

//Display the caption
$('#slideshow-caption').css({opacity: 0.7, bottom:0});


//Hide the caption first, and then set and display the caption
$('#slideshow-caption').animate({bottom:-70}, 300,() {

//Display the content
$('#slideshow-caption h3').html(title);
$('#slideshow-caption p').html(desc);
$('#slideshow-caption').animate({bottom:0}, 500);

The above lines of code control the captions displaying/hiding, the height of said caption area, opacity, etc.  In both cases, I replaced “bottom” with “right” just to see what happened.  What happened was the text didn’t slide at all – it just stayed there until the next slide – precisely what I really wanted to do anyway.  Some styling with @font-face for the captions and, voila, a working alternative to the Flash slideshow.

See the final product here: The Art of Eyebrows


2e6c0a0ecb51c9d67263485a1713294d How I broke a javascript gallery script to make a Flash like slideshowChris Reynolds is one half of Arcane Palette and writes the majority of the blog posts on this site. He also has a personal blog, jazzsequence, where he shares links, videos, thoughts about music, technology and gaming, and posts various personal music and writing projects.

About Face

Increasingly, the new big thing in web design is the inclusion of @font-face in CSS3 and most modern browsers.  Why is @font-face such a big deal?  To understand that, you must first understand the limitations of web design in the past as it applies to typefaces.  To that end, a personal anecdote:

Like thousands of others, my first websites were hosted on GeoCities.  Back then, a cool URL didn’t matter (and was more or less unattainable by non-corporate types anyway), and there wasn’t such a thing as “Googling”.  So, while today it sounds quaint, a network hosting thousands of websites for free, in specialized “districts” based on your interests (or the topic of the site), that you could then explore and browse to see your neighbors was pretty cool.  Much like MySpace, GeoCities gave you the tools to design your website by hand or pick from one of several different templates (and, also like MySpace, this had the result of creating a lot of truly hideous websites).  The best part of GeoCities, for me, was it became a sandbox to learn and play with HTML.  One thing I liked to experiment with was using different fonts I found online on my site.  This was generally as simple as saying <font face=”NameOfFont”> in the source code of the page.  Once I put the right font name in there, that site would have some pretty cool (or, alternately, really gaudy-but-I-thought-it-was-cool-at-the-time) titles or headings.  However, once I went to another computer, my fantastic fonts I spent so long hunting down and embedding would be gone.

The reason for this is because when you declare a font on a webpage, your browser looks through the installed fonts on  your computer for the appropriate font.  If it doesn’t find it, it goes back to the backup font, or, lacking that, some browser- or Operating System-specific default font.  And this is what web designers have been fighting with since the beginning of time (or at least, the Internet).  We’re faced with using the lesser of the evils, choosing a font that looks more or less the same on all computers, or using a fantastic font that only a small handful of people can see.

There are a number of ways to get around this, most of them aren’t fantastic.  You can use images to render your graphical fonts.  This is great from a design standpoint, but not so good from a search engine optimization standpoint — images are meaningless to search engines which only scan a page for text.  There are several methods for converting your font into an embedded Flash object (i.e. sIFR) or rendering it with javascript (Cufon), both of which take time to run the script, and therefore slow down your site.  Then there’s the copyright implications.  Some fonts were designed by hobbyists or designers who do other things primarily and are given away for fee.  Some fonts specifically say “free, but for personal use only.” And some fonts are strictly corporate and cannot be shared without purchasing a license.  Thus we are relegated to using a small handful of fonts that are safe for all Operating Systems, and various means of faking it for other fonts that we think are cool.

@font-face changes that.  Sort of.  What it does is enable designers to embed a font into the stylesheet of the site.  This means that when the page loads, the font downloads to the viewer’s computer the same as any other image on the site.  This kind of font embedding isn’t really all that new — in fact, it’s been around for a while (although not all browsers have supported it).  But increasingly, font designers and foundries are finding methods to make their fonts available for public use — either by going through a membership-based system like TypeKit – or by joining in a growing movement for openness and “free as in beer” fonts.

This is exciting for people like us, who have lamented the lack of choice for typefaces in web design, and have used a variety of methods for faking it in the sites we build (Arcane Palette, itself, uses a “hack” of sorts — we use a WordPress plugin called TTFTitles which converts letters into images and renders the words as transparent pngs).  Now we don’t have to fake it — assuming the font was released with a non-restrictive license, we can use the real thing, decreasing loading times and eliminating the need for javascript or Flash or any other sort of third-party software to render the font correctly.  Or, through a service like TypeKit, designers can choose from a huge collection of premium, professional fonts that they are free to use on their site (according to the terms of their membership plan).  In those cases, the font designers get credit and compensation for the work they put in to creating the font (not a small undertaking), and designers have the freedom to choose the best font face for the site they are building without limitation.

In an upcoming post, I will share the method for using @font-face in web design that we use, as well as some great free resources we’ve found along the way.  The future of the web is exciting, and you can expect more and more complexity and creativity in design in the coming months and years.


2e6c0a0ecb51c9d67263485a1713294d About FaceChris Reynolds is one half of Arcane Palette and writes the majority of the blog posts on this site. He also has a personal blog, jazzsequence, where he shares links, videos, thoughts about music, technology and gaming, and posts various personal music and writing projects.