The three changes I’ve made are fairly small and revolve around the Body Size Comparison section of four fonts. I’ve substituted Verdana for Tim’s choice of Times New Roman, as Times is rarely used on the web. Verdana, on the other hand, is probably the most widely used and most readable web font of all.

To further aid in this comparison, I’ve shifted the specimen’s font to the right one position. It now has Georgia on its left, and Verdana on its right, with Arial taking the far right position. This way, whether you’re testing a serif or sans within WFS, your font is always adjacent to both its style mate and complement for easy compare and contrast.

Finally, I’ve added a paragraph set in each of the four fonts beneath the comparison section. The whole point of evaluating web type is to ensure that it is legible, suitable—and don’t forget beautiful—when set in the browser. Now you can compare how well your font works in paragraph form against these three web stalwarts.

And, just as you can use FontFriend with the WFS, you can use it with the Soma WFS.

Enough with the chit-chat. View the orignal. View the Soma WFS. Or, grab the Soma Web Font Specimen zip. Go make beautiful type on the web.

One very cool component of this release is that Typekit—who Tim now works for—has integrated the Web Font Specimen into their service. See, for example, FF Meta Serif Web Pro Book.

But the part that makes me blush is that Tim decided to include FontFriend on the new Web Font Specimen homepage as an ideal companion to the specimen. In order to feel like I deserved a spot on there, I’ve added a special feature to FontFriend: it now detects if you’re on the Web Font Specimen demo and automatically updates the font name when you select a font family.

Don’t have FontFriend yet? Go to the FontFriend project page and get it now.

But, for those looking to find the best quality free webfonts, the good folks at Good Web Fonts have put together an excellent list of high-quality free fonts suitable for web use. I’ve discovered some hidden gems there, and it’s now first on my list of places to consult when deciding on a webfont for a new design.

As awesome as they were, they required an explicit width. This meant that they didn’t adapt gracefully to different labels—you had to explicitly set a width on the buttons that might not fit the actual label properly. This had been necessary to get the nice inner white border, which I’m now using two instances of inset box-shadow to replicate (many CSS3 declarations allow for multiples, such as background-image and box-shadow). I would have preferred to do it with only one declaration, but box-shadow: 0 0 1px #fff inset; produced too dim of an inner border for my liking.

I also wanted a better-looking button depressed state. I emulated the inner shadow typical of OS X Leopard-era buttons with a third inset box-shadow on the :active state, as you can see below. Pressing the buttons feels really awesome if your browser supports CSS Transitions.

States: Normal, Hover, Active (left to right)

Speaking of CSS transitions, they’re now used consistently on the :hover state, by changing the background-color on hover instead of changing the gradient (gradients don’t currently animate in a transition). I also did a bit more work to make it cross-browser friendly: I used backup colors wherever rgba() notation was used, as well as a gradient.png fallback for browsers incapable of CSS gradients.

Here’s a few things I found along the way:

• Firefox 3.7 nightly (which will be FF4 eventually I think) renders the buttons the best.
• WebKit doesn’t actually support inset box-shadow yet in Safari 4 or Mobile Safari. So, they get left behind for now. But WebKit nightly and Chrome have landed support for inset box-shadow.
• WebKit currently has a fascinating bug with inset box-shadow and transitions. Using WebKit nightly or Chrome, try clicking on the “Wonky Webkit Transition” button. The box-shadow starts on the outside and then snaps to the inside at the end of the transition.
• Firefox does weird things with an :after pseudo-element placed on a button element. I did some hacky things to work around that at the default size using @-moz-document. Not awesome or recommended.

Without further ado (and I use the phrase only to plead with the people of the world who say “without further adieu” to STOP DOING IT WRONG), check out the Realistic CSS3 Buttons Redux demo.

Then Jay on the Inference blog shared his CSS3 implementation of Rundle’s buttons to great effect. He also explicitly shows the design details (with excellent diagrams) that make for press-able buttons. But, sadly, there was very little “3” in the CSS3, only making use of border-radius and rgba colors. Also, he resorted to 3 layers of nested <b> elements inside the <a> elements to implement his effect. I knew that this could be done with leaner markup, more CSS3 goodies, zero images, and way more flexibility. (Note: this isn’t a critique of Jay’s good work - just an instance where someone inspires you to try to do better.)

The end result uses markup that looks like this:

<a href="#" class="button">Pushit</a>

And looks like this:

States: Normal, Hover/Focus, Active (left to right)

Well, it looks that way in Firefox (3.6+), Safari & Chrome. I haven’t even tested in IE and don’t care to. I’m sure that it’d be possible to do this in with proper progressive enhancement, but this was about testing the boundaries of CSS3.

I’m not going to break down the code here. That’s what Firebug/Inspector/View Source are for. But here are some notes:

• The biggest weakness by far is that I needed to set an explicit width on the buttons. I couldn’t find a way around this and maintain my no-extra-markup challenge. Consistent widths might actually be an advantage in certain contexts. (There are some classes to provide for different widths.)
• CSS3 gradients galore. Not an image in sight.
• The extra borders are created using :after and :before pseudo-elements.
• The CSS3 gradients use rgba color notation with alpha values so that you can have different coloured buttons by changing only the background-color. (I assigned a few colour examples to extra classes)
• Real <input type="submit" /> buttons don’t allow :after and :before pseudo-elements. Form elements are weird.
• CSS gradients are currently avoided by -webkit/-moz-transition. Brief googling indicated performance concerns. If you wanted the ooh shiny™, you could change the background-color on the :hover/:active states instead. I avoided this because I only wanted to have to declare a single background-color for color classes, but tried it in the obviously-labeled button.

Tired of reading? Look at some realistic looking CSS3(-only) buttons. And if anyone has any ideas about how to overcome the fixed-width requirement, do share!

Goodbye Mouse, Hello Hands

How much of your site depends on mouse hover states? Hopefully none, if you’re committed to accessibility. But, chances are there are parts that labour under the assumption that everyone is—and always will be—using a mouse. If touch computing replaces the mouse + keyboard paradigm that’s dominant today, there’s going to be a lot of scurrying to retrofit websites to be usable by folks getting their hands on your site. I know that I’m not going to make anything rely on mouse hover states from here on out.

But that’s merely a technical hurdle. There’s a fundamental difference between an interaction with your screen mediated by a mouse and reaching out and touching something. Your website will no longer have clicks; it will have users touching, pinching, swiping, rotating. In short, the touch experience is flush with potential for a richer, more textured interaction paradigm in our websites. Touch might be as large a paradigm shift beyond today’s web as the web has been over print.

Goodbye Landscape, Hello Portrait

Computer monitors have always had a landscape orientation. This has only become more prominent in recent years as we moved from ubiquitous 4:3 ratios to various widescreen formats. In short, we’ve had ample width and short heights. (Thus the religious wars over “the fold.”)

But here we have a 3:4 orientation. Portrait. Does portrait encourage vertical scanning instead of horizontal? What does it mean to relax about how high on the page our central content is? How many assumptions about how the web works do we have that are based on the landscape orientation?

You might wish to inform me that the screen can just as easily be used in landscape, but my money’s on people using it in portrait more often than not. But even that ability to choose has big implications for our assumptions about designing for the web.

Goodbye Flash, Hello Web Standards

Virtual ink is being spilled with abandon over the iPad and Flash support. Flash gained traction because web standards were deficient in 2 core areas: video and animation. HTML5 has the video element, and animation via canvas, SVG, CSS animations, and plain ol’ JavaScript can do 98% of the things that Flash is currently used for.

More importantly, web standards can do 100% of the desirable things that Flash can do. Those technologies aren’t yet supported by every browser, but they are supported by Safari, and that’s all that matters here. And are you really going to miss those punch a monkey banner ads?

The two things preventing Flash’s demise are 1) momentum and 2) authoring tools. The former is shifting thanks to the iPhone and iPad, and the latter is bound to change.

Goodbye Fringe, Hello Mainstream

Browsing on the iPhone can be frustrating when the content you’re looking for is all Flash. Other times the site has simply been overly optimized for the desktop and/or Internet Explorer. Some may blame the device, but as the iPhone continues to grow and the iPad emerges, it’ll be business suicide to have a poor experience in the mobile sector. Let’s face it - users with enough money to spend on an iPhone and/or an iPad are exactly the types of people that most businesses want to appeal to.

In short, web designers who understand how to design good web experiences for these platforms will only become more sought after. And this just might allow me to justify an iPad as a business expense.

But what I really want to talk about was one of the questions Tim asked me but chose not to publish on his site, which was:

So about the missing characters in Chunk. What if you didn’t have an alternative (like if you needed an ampersand)? Would you substitute one from another typeface? Which typeface?

After mentioning that I didn’t much care about the missing glyphs for such a small site as mine, I went on to say:

For a font with glyphs missing, you fall back in your CSS stack to the next font that has the glyph. This is the premise that Typekit works on when it splits fonts into two pieces and then puts something like font-family: skolar-1, skolar-2, serif; in its CSS rules. If I had found a complimentary typeface (with appropriate licensing) and wanted it just for the glyphs that Chunk was missing, I could make a small, subsetted version of it (remove all the glyphs that Chunk already has), embed it as well with @font-face and put it after Chunk in the font stack.

After my chat with Tim, I became a little fixated on trying to find just such a suitable subsetted fallback. I went over to Font Squirrel and came up with two possible free replacements: CollegiateFLF Black and Bender Black. After downloading, I re-uploaded them through Font Squirrel’s marvelous @font-face Generator in order to subset the fonts down to only glyphs that aren’t already in Chunk (more or less). Subsetting only the glyphs you need can create dramatically smaller font files, speeding up your site. I chose to only include Punctuation and Alt Punctuation, as shown in the image below (click for larger):

So, what did it look like? Not that great unfortunately. Chunk is just far too unique to play well with (freely available) others. I tried three different stacks, falling back to either 1) Impact, 2) Collegiate Black and 3) Bender Black. Have a look: MIA Glyphs, or just see the image below.

I think that Collegiate Black comes the closest, but its dollar sign and ampersand are a terrible match for Chunk. Bender is entirely ill-suited, and Impact isn’t much better. None of the apostrophes look similar to Chunk’s comma, which is what I would hope to see in a well-suited fallback.

The closest I came to being happy was with Impact as a fallback for apostrophes (the only glyph I needed that Chunk lacked). I created a version of thatwasnotok.com that used a pseudo-bold Impact for apostrophes where they were called for: Impact apostrophes. I also had to surround the apostrophes in a span element to nudge them into place.

I hope that this somewhat fruitless exercise was of interest to people trying to make  fonts work on the web. Many of the free fonts that allow @font-face embedding suffer from absent glyphs, so using a subsetted fallback may be a lifesaver for you. As for me, I’m still not sure if I’ll push the Impact apostrophe’d version live or keep the version with primes. Anyone have an opinion?

Have you ever found yourself in a social setting where someone’s inadequate social skills cause consternation to everyone around them? Of course you have. Have you ever wished there was a way to discreetly tell them that their behaviour is not OK?

Now you can. That Was Not OK is here to help. Print the cards, and keep them in your wallet for just just such situations.

The Design

For the web nerds out there, this turned out to be a fun showcase for what can be done with native font embedding via @font-face. Thanks to Jonathan Snook, Paul Irish and Font Squirrel for their terrific work in taking font embedding from a new and untested technology to an increasingly viable tool in the web design toolbelt.

For the embedded font, I turned to The League of Moveable Type’s brash Chunk, an ultra-bold slab serif that helped the typography shout at you. (If the font were less intimidating, I’d ask it why it’s missing an ampersand and smart quotes.) I found that the all-caps main title needed some serious kerning, but I’m really happy with the end product.

Why it took so long for custom web fonts to become an in-browser reality is a tangled tale involving browser wars, font foundry fears and a general inertia of rest. Many thorny licensing issues remain regarding the use of commercial fonts on the web, which is why there’s been a proliferation of third-party solutions such as TypeKit, Fontdeck and Kernest cropping up.

But there are also headache-free choices such as the excellent free fonts from Jos Buivenga’s exljbris Font Foundry. Since Jos explicitly allows @font-face embedding, this site uses his excellent Delicious font for menus and headings, and will run smoother and faster than ever thanks to ditching sIFR’s Flash dependency.

Not all is sunshine and roses. The iPhone version of Safari has disabled @font-face linking for some reason unknown to me. IE has its own proprietary format that involves acronyms like EOT and WEFT, alongside a high probability of animal sacrifice to appease the demons who designed WEFT. But there is a light at the end of tunnel, and we’ve stepped through it.

Features added in 1.0 include:

• a field for a custom font (you’re not restricted to my extremely well-though out list)
• a button to reset all styles (also handy for pages with loads of inline styles!)
• default selector is body rather than h1,h2,h3…

I haven’t received any reports of bugs, because I’m so awesome. Well, I did add a bit more defensive CSS to deal with overlapping site styles. And, if my awesomeness has dimmed and a bug has crept in, let me know in the comments. And if you missed the link above, go to FontFriend’s project page for full details