Readable Web » JavaScript

A Webfont Specimen Page Free For Download

Richard Fink — Sun, 10 Jul 2011 15:53:36 +0000

Tim Brown of Typekit put together a webfont specimen page awhile back. Originally introduced in Tim’s article for AListApart: Real Web Type in Real Web Context, and it does give a real nice view of a font in a variety of contexts.

I’ve incorporated a modified version of it into my suite of web font test pages. And, for those who might find it useful, you can take a quick look at it here, and download it here.

The Modifications

There’s two main differences between my version and Tim’s:

For test pages, I like to keep everything – the HTML, CSS, JavaScript, and even images – contained in a single file. As my webfont test pages have evolved, I’ve just found it simpler this way. At least to me. So everything is in one .htm file. The two images from the original – used for background – are included as Data URIs in the CSS. The only downside is that those images won’t show up in IE6 or 7: a situation that doesn’t bother me because nearly all the functionality remains intact and my IE testing is usually done on IE8. (IE6, 7, and 8 all require EOT, and Windows GDI is the rendering engine for all, and I’ve yet to see a font problem appear in IE6 or IE7 that didn’t show up in IE8.)
The @font-face syntax has been updated to use the “Fontspring”, single declaration syntax.
See: Further Hardening of the Bulletproof Syntax and Best Practices for Serving Webfonts to IE9 on the Fontspring blog for more information.

Pause Before You Say “IE Sucks”

An interesting glitch appeared while I was working on this. When displaying the font Ultra from Google Webfonts, there was a strange difference between IE8 and Chrome. In IE8, the glyph “j” was clipped off on the left like this:

But Chrome rendered the entire glyph and allowed the part that IE clips off to extend outside the bounding box to the left:

In both cases, it’s not what you want.
Which browser is doing the technically correct thing? And more importantly, what’s causing it? Since the clipped “j” in IE was more of an eyesore, the kneejerk response for most developers would be, I think, “Goddam IE! Again!”. But after opening the Ultra font in a font viewer, the real source of the problem revealed itself.
In the font itself, the position of the left sidebearing of the “j” was the source of the problem:
You can see that the font itself “clips” the “j”. (And this may or may not show up depending upon the layout.)

Over the past eight months I have cracked open many hundreds of fonts, one after the other. And I can tell you firsthand that even on carefully made fonts, stuff like this happens a lot. Ultra was designed by Brian J. Bonislawsky of Astigmatic who’s very experienced. But even so, stuff happens. So, before you go blaming the browser, if you’re using a webfont, remember that a new variable has been added to the mix – and the source of what seems like “buggy” behavior is just as likely to be there as anywhere else. Just what web developers needed, a new complication!

Some Cool Tools That Came Into Play

The CSS for Tim Brown’s page was originally in three separate CSS files. I brought them together within a single style tag using a nifty free tool – CSS Mixer – which allows you to select a bunch of CSS files, concatenate them into a single file, and minify the code using the Yahoo User Interface Library. After that, it’s cut and paste. Very handy. There is also a tool by the same developer, Sam Beauvois, for concatenating and minifying JavaScript named JS Mixer. (They’re .NET executables for Windows only. No Mac or Nix versions unfortunately.)

That’s it. Pay it forward.

Readable Web At AnEventApart, Boston

Richard Fink — Sun, 23 May 2010 16:05:23 +0000

Boston, Massachusetts Readable Web is getting out of the office this year. I’ll be attending and reporting on a wide variety of events.

Starting with:

AnEventApart, Boston

I’ve never attended one of Zeldman & Meyer’s traveling road shows before and I can’t wait. The event kicks off tonight with a meet and greet at the Westin Copley Hotel sponsored by Extensis who is here to preview their new web font service WebInk.

Over the next few days I’ll be posting pics, twittering, muttering, commenting about just how tall Jeff Veen really looks in person, and reporting on everything and anything that happens to spark an idea in my brain.

Details on this conference and upcoming Event Apart conferences here.

Update: After-Conference Thoughts

Call it what you want: web design, digital publishing, whatever – the problems exist on two levels.

Problem 1: Cutting The Bullshit

This problem is not unique to digital publishing but to all publishing: staying on message, staying focused, writing clearly, keeping it brief – all the trite truisms are just as true today as they were when David Ogilvy wrote Ogilvy On Advertising in 1983 and Rudolph Flesch wrote The Art Of Readable Writing in 1949. Nobody is going to give you or your product more than a passing glance. At least at first. Waste people’s time and they’re gone. Click.

This is why I perked up when Luke Wroblewski argued that you should design your small-screen mobile experience first and build your desktop experience from that kernel. I agree. Working from the inside out like that imposes a discipline that would probably not exist if you started with the desktop experience. And if you can’t seem to cut it all down to it’s essence for an iPhone or Android, it’s time to ask yourself why the site exists in the first place.

Problem 2: Re-Tasking Content For Different Devices And Screen Sizes

It used to be that the difference between user agents (browsers) was the thing that drove web authors crazy. Yes, there are still issues, but it’s easy to envision a time in the near future when that won’t be anything more than an occasional and minor annoyance. The monster facing us now is different devices and screen sizes. This is a tough one – and the mental tools publishers need are just beginning to coalesce.

Recently, on Typophile.com, designer John Hudson made the observation that, to him, websites in general resembled scrapbooks. For some reason I’ve been thinking about that comment a lot and finally realized why: minus the negative connotations of the word “scrap”, they are scrapbooks. Chunks of information being fed in and out from disparate sources on the network and placed together on the same “page”. The equivalent of taking chunks of five or six pages of a book or magazine and pasting them together. Even in an era of relatively high resolution screens this will still be the case. Content must be chunked so it can reflow into its container. And connectedness is a requirement – the idea of an “e-book” on an “e-reader” disconnected from the net is already preposterous – even though we’ll be living with that situation for some time to come.

I got a new TV delivered today. It’s connected to the network, too. A TV with web apps. A giant iPad. Who’d a thunk?

And, oh, yeah. Just to cap off AnEventApart, Boston:

How Tall Is Jeffrey Veen?

Meeting Jeff Veen in person was a bit of a shock, really. For a guy who writes and speaks about all this web stuff, turns out the guy’s tall enough to be my father!

Oops, Capped Off Too Soon

[A Bit More On An EventApart, Boston] Here’s a nice roundup of the event called Themes From AnEventApart Boston with a link also, to Luke Wroblewski’s extensive notes from the conference. Also, Luke and the concept of “Mobile First” gets a treatment on the Big Web Show.

New Javascript Tool Takes Aim At Web-Site Readability

Richard Fink — Mon, 25 May 2009 22:37:58 +0000

90% of the Web is words, words, and more words. And yet it isn’t a very friendly place for quiet, prolonged reading. That’s a problem this blog means to attack.
So naturally I take special notice of sites or products promising “Readability”.
Recently, on web-standards guru Jeffrey Zeldman’s blog there was a post which mentions briefly, in passing, “Arc90′s awesome Readability plug-in”.
A readability plug-in? Awesome? Then I noticed there was also a mention on web designer Jeremy Keith’s blog, too.
So this I had to see.
Report: It turns out “Readability” is not actually a plug-in or an add-on. As it’s currently designed it’s what’s called a JavaScript Favelet or Bookmarklet. What happens is this:
On the download page, you choose from certain pre-defined formatting options and there’s a box with some sample text that shows you how those options behave.
Then, when it looks right to you, you can save the result as a Bookmark. You do this either by right-clicking the Readability button and selecting “Save As Bookmark” or by dragging the button up to your Bookmarks menu.
You then have a Bookmarklet (or Favelet) named Readability in your Bookmarks or Favorites menu.
From then on, when you go to a site and you’d like to focus in on just the main article, without ads or other distractions, you can click on the Readability bookmark and that’s what you get: just the article, formatted according to the selections you made back at the download page when you created it.
(Tip: You can make and save different versions of the favelet by playing around with the settings and saving each variation under a different name, like: Readability-Newspaper, Readability-eBook, etc…)
Check it out:
Readability Favelet
In other words, it works kind of like an ad-blocker on steroids, filtering out everything but the text of the main article.
After playing around with it for awhile, I can tell you that you’ll see mixed results depending upon the page, and the browser you’re using.
But still, it’s a nice try and still under development.
In a few weeks, I’ll be returning to take another look. No stranger to creating Favelets myself, I’ll analyze exactly how Readability Favelet works under the hood, how it does what it does, and how it compares with alternate style sheets and FireFox Add-ons.