Readable Web » Design

In Web Design, The Narrow Column Is King

Richard Fink — Sat, 10 Mar 2012 17:01:29 +0000

Get used to it. Learn to live with it. Make it work for you.

Check this out: Re-Thinking The Mobile Web
It takes a good twenty minutes to get through but it’s worth it. Even if you are already familiar with the pitfalls of trying to accommodate all the different screen sizes out there. Maybe especially if you’re already familiar with the pitfalls.

My friend Jerry Maddox – Professor of Art and teacher of New Media Design at Penn State is totally on the right track. He’s obsessed with finding the absolute minimal one-column layout with as little CSS as possible. Something that can be committed completely to memory, preferably. Here’s the latest iteration featuring the same text and CSS using each of 5 free open-source web fonts of high visual quality.

A Free RasterBRIDGE® Web Font: Puffbuddy Light

Richard Fink — Wed, 29 Feb 2012 20:03:46 +0000

What you see above is a screen shot taken on Windows XP.
It looks smooth and clean, right?
Unlike most so-called ‘web fonts’, all RasterBRIDGE® Web Fonts are specially prepared to look as good in Windows as they do on the Mac,
and on the iPad,
and on the iPhone,
and on the Kindle Fire, and so on and so forth.
Before we ship, we test the font in a wide variety of browsers on all major platforms and devices.

As a RasterBRIDGE® Web Font, Puffbuddy Light will remain balloony, buoyant, and jolly in any browser, on any platform.
Download it here and spread the word. Enjoy.

What’s The Font Got?

Puffbuddy Light features the HTML Basics+ Character Set. That means you get all the important HTML character entities, a full complement of spacing characters and you’re covered for the following languages:

• English, Spanish, German, French, Italian, Portuguese, Irish, Finnish, Icelandic, Norwegian, and Swedish.

RasterBRIDGE® Web Fonts Stay Small and Load Fast

RasterBRIDGE® Web Fonts are specially compressed to stay small and load fast. The Puffbuddy Light TTF font file weighs in at only 41 kb, the Woff at 28kb, and the EOT at 26kb. A whole font for the size of a small image!
And did we mention that, for the “price” of those 28 kilobytes compressed, the HTML Basics+ Character Set also covers these languages, too:

Basque, Albanian, Gaelic (Irish), Gaelic (Manx), Gaelic (Scottish), Luxembourgish, Afrikaans, Haitian_Creole, Indonesian, Javanese, Estonian, Fijian, Filipino/Tagalog, Afar, Bislama, Breton, Chamorro, Comorian, Faroese, Gilbertiese/Kiribati, Kinyanwanda, Kirundi, Luba/Ciluba/Kasai, Malagasy, Malay, Marquesan, Ndebele, Oromo, Palauan/Belauan, Quechua, Romansh, Sango, Sesotho, Setswana/Sitswa, Seychellois_Creole, SiSwati/Swati/Swazi, Somali, Sotho, Swahili, Tetum, Tok_Pisin, Tongan, Tsonga, Tswana, Tuvaluan, Uzbek/Usbek, Walloon, Xhosa, and Zulu.

¡WOW!
Ett stort värde. Ein großer Wert. A mikils virði. Yon gwo valè. Një vlerë e madhe.

The Inclusionists

Richard Fink — Sat, 18 Feb 2012 04:10:25 +0000

There is a bit of a kerfuffle going on in the world of web standards regarding the use of vendor specific prefixes for CSS properties. There’s an article on AListApart about it that every web developer or anybody in “e-publishing”, for that matter, should read.

A Comment From A Fellow Inclusionist

One commenter had this to say:

“What do you expect when the same evangelists that promote standards, promote no-portfolio CSS “geniuses” that do nothing but create experimental stuff like pink gradient goodies signing ‘sorry, didn’t have time to test in FF or IE’.
If these people had only one past work experience in a normal enterprise or a governmental institution, they’d understand what cross-browser and accessible really means and how we’re busting our behinds everyday making sure things work for everybody.”

Philosophically, this is where I stand, too. (Minus the slightly, maybe, too misconstruably homophobic and/or chauvinist “pink gradients”. Purple would have done just fine.)
Alright, go ahead, call me an HTML Inclusionist, I don’t care.

Me in my web dev days at New York Transit, sans beard and looking like Jimmy Hoffa just before the hit.

I cut my eyeteeth in web development at a governmental institution: The New York City Transit Authority. In my experience, if you work for a company with a web site facing outside (not an intranet), a site where actual customers come, you better get it working acceptably across the browser spectrum or you will get your head handed to you. Or a pink slip. Or both.

And rightfully so. Welcome to the real world.

Practical Font Design, Third Edition

Richard Fink — Thu, 01 Dec 2011 17:29:12 +0000

Practical Font Design
3rd Edition

In Digital Publishing you need to co-ordinate your efforts with many people. Web designers, developers, server techs – the list goes on and on – and the more you know about how those people go about their work, the better off you will be.

With fonts, the “collaboration” might take the form of a purchase, or a free download, or just a link to the font in your HTML. But there is a font-maker somewhere on the other end of that transaction. And the more you know about how that font came to be, the better off you’ll be. And unlike a lot of things in today’s fast-paced environment – where it’s hard to separate the side-shows from the main attractions – a knowledge of fonts and how they’re made won’t be obsolete in just a few years. Changes in font technology come at a snail’s pace, and what changes do come, are incremental. So what you learn about fonts will pay dividends for as long as you live. Really.

Have A “Practical” Christmas

David Bergsland’s Practical Font Design is now in its Third Edition. It’s greatly improved in many, many ways from the Second Edition. (Bergsland not only listens to reader feedback, but he acts on it, too.) It’s still the only book of its kind, and it does a simple thing: it tells you, in a friendly and to-the-point manner, how one experienced font designer and teacher – David Bergsland – goes about his work. It’s a must-buy for font designers. It’s a should-buy for any web designer, graphic designer, or anybody involved with digital publishing.
Not much interested in the technical details? – It’s worth the price just for the “history of type” section and as a flip-through reference. If you’ve ever used Adobe Illustrator or CorelDraw, you already know more than you necessarily need. And a demo download of FontLab Studio – the professional level font editor referenced in the book – is available for Mac and Windows free.

Here’s a little piece to give you an idea of the tone:

“My plan is to go through my decision making process so you can do the same as you develop your fonts. There is no right or wrong here. All you have to guide you in the process is your personal sense of style – what’s right and wrong.”

Practical Font Design, The Links:

Amazon Print and Kindle

Lulu PDF

Lulu Paperback

David Bergsland sells his fonts at:

Hackberry-Fonts

And blogs here, dispensing technical tips and helpful font-making tools:

Hackberry-Fonts Blog

Extensis Brings Google Web Fonts Straight Into Photoshop

Richard Fink — Mon, 07 Nov 2011 23:42:10 +0000

Extensis, the company behind the WebINK web font service, today announced a plug-in that brings Google Web Fonts straight into Photoshop.

Free And Open-Source Fonts Served Alongside The Proprietary, In A Surprising Twist

Since launching the WebINK web font service, Extensis has concentrated on building a library of fonts drawn from the proprietary type community, building on long-standing relationships developed through Extensis’ other font and design products: Suitcase Fusion (a desktop font manager) and Universal Type Server (a server-based font library and font license manager for workgroups).
But they haven’t left it at just being another service operating in the shadow of (now Adobe) Typekit – as services like Fontdeck, WebType, and others have done. From day one, I’ve personally seen them strive to find new ways to meet the needs of web designers with innovative software tools that, in combination with their hosting service, make the use of a font service – as opposed to shopping the web for suitable fonts and then self-hosting – a much easier and useful proposition. They’ve continuously shown up at the major web conferences to promote, of course, but also to watch and learn and listen. What’s sets them apart is that they turn around and act on that knowledge in creative ways.

Riding Piggy Back On Google’s Web Font Initiative

[A developing story... more analysis, riding in on piggy-back, is on the way...]

Adobe Announces Acquisition Of Typekit

Richard Fink — Mon, 03 Oct 2011 19:43:00 +0000

It’s fair to say that those close to the development of Web Fonts expected Typekit to be acquired by somebody. Well, today somebody did.

Adobe Buys Phonegap And Typekit for Better Web Tools

The Typekit Blog Announcement

And Adobe’s press release: Adobe Acquires Web Typography Innovator Typekit

A good thing? A bad thing? An inconsequential thing? Who knows?

A Nice Use Of Web Fonts In Mainstream Media

Richard Fink — Fri, 09 Sep 2011 00:16:10 +0000

There’s a nice use of web fonts at the New York Times. (Just remember to clear your cookies to keep on reading past their twenty page a month limit.)

Titled The Reckoning , it’s a link and teaser page for a group of stories about 9/11.

Very tasteful and dutifully solemn.

Definitely not cheesy.

We don’t want cheese.

Worth a look. Really. Except for the upper case “G” with a pimple on its chin. Is this some kind of slick reference to Lincoln? Or Lincoln’s well-documented love of pizza? We’ll probably never know for sure.

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.

New @Font-Face Syntax: Simpler, Easier

Richard Fink — Mon, 07 Feb 2011 17:51:59 +0000

I love it when a plan comes together.

Some months ago, in an an email exchange with Jeffrey Zeldman about the feasibility of a book about web fonts, I wrote that the turning point – the point at which enough would be known to establish best practices – would be around the time IE9 and Firefox 4 were released to market.

A Simple And Conformant Cross Browser Syntax

Now, with IE9 and FF4 nearing release, as if on cue, Ethan Dunham of Font Squirrel has revisited the problem of a cross-browser CSS @Font-Face syntax and found – a year and half after it first became an issue – a new and simpler solution. This was last Thursday.

Only on the web could change happen so fast. Knowledgeable eyeballs were on it immediately. And within hours of publication, it was tested and tweaked a few times. By the end of the day it was already being implemented at Font Squirrel, Font Spring, and Kernest, too.

It Comes In Two Flavors

Since one of the things I do like about the Mo’ Bulletproofer syntax is that, while the following is conformant:

     src: url('http://:/') format('no-ie-404')

it’s obviously odd and deliberately self-describing. Therefore it’s less likely to be left out once you’re in the habit of using it. And less likely to be deleted accidentally by someone unfamiliar with it’s purpose. So, the following is my version of the new syntax, in line with that practice. It’s the result of tests done with the IE9 Preview 7 build and many other desktop browsers and platforms over the weekend.

The Trick Is In The Question Mark

There are currently two variations. They are:

@font-face {
     font-family: 'fishyfont';
     src: url('fishyfont.eot?iefix') format('embedded-opentype'),
	   url('fishyfont.woff') format('woff'),
	   url('fishyfont.ttf')  format('truetype'),
	   url('fishyfont.svg#svgFontName') format('svg');
	}

With this variation, IE 6, 7, 8 and IE9 take the EOT file. But, of course, IE9 supports WOFF, too. So what if, for some reason, you want IE9 to take the WOFF file instead?

Follow The Bouncing Ball

Well, the ball that was set bouncing with Ethan’s original post on the Font Spring Blog bounced back again from Melbourne, Australia where Ryan Seddon of CSS Ninja posted a fix that overcomes this limitation:

@font-face {
     font-family: 'fishyfont';
     src: url('fishyfont.eot?iefix') format('ie9-skip-eot'),
           url('fishyfont.woff') format('woff'),
           url('fishyfont.ttf') format('truetype'),
           url('fishyfont.svg#svgFontName') format('svg');
	}

With this variation, IE9 will not take the EOT. Instead it takes the next font in the stack that’s in a format that IE9 understands. In this case the WOFF file. If there was no WOFF file, it would take the TTF. (That is, as long as the TTF has the hidden embedding bit set to “Installable” – if Microsoft is still sticking to that. I’m not sure what IE9 does in that case, we’ll see.)

It’s Still Being Tested

There’s no such thing as too many tests or testers. If you find a problem, please report it on the Font Spring Blog. Or here.

I’ll be posting more as I test more and to explain how and why all this works and what problems it solves.

Update: Feb 17 2011

Alert: In some quick-and-dirty tests of this syntax in IE9 RC1, a problem came up. If the page kicks IE9 into a “less than” IE9 Compatibility Mode, this technique fails and the fallback font displays. The word from Microsoft’s IE team is that this behavior will not be altered for IE9 RTM.

[Let's get it over with: insert, mentally, your expletive of choice here and now, and then let's move on....]

What this means is that, as of right now, the most comprehensive, failure-proof method – one that avoids the bug in Android, the innate strangeness of the local() descriptor, and bridges the gap between IE6, 7, 8, and IE9 – is the Mo’ Bulletproofer @Font-Face Syntax. However! However! If you prefer a single declaration solution and your pages don’t trigger one of the IE9 Compatibility Modes, barring any more unforeseen changes between IE9 RC1 and IE9 RTM, the Fontspring syntax seems alive and well. The problem won’t come up. Note also, that you can near-totally prevent failure and ensure your pages are running in IE9 “Edge” mode by using the X-UA-Compatible Meta Tag.

Update: March 02 2011

Alert: More changes, but I think we are finally at the end. Maybe. Ethan Dunham has “hardened” the syntax by adding in the EOT-only src descriptor that was a part of Paul Irish’s Bulletproof Syntax. And it works in IE9′s compatibility modes, too. (I can’t see a downside. In fact, adding that first EOT-only src descriptor was Microsoft’s recommended approach to bridging the gap between IE 6, 7, and 8′s proprietary implementation and IE9′s standards-based implementation from the very start.)
So, the following now works universally:

@font-face {
	font-family: 'fishyfont';
	src: url('fishyfont.eot'); /* IE9 Compat Modes */
	src: url('fishyfont.eot?iefix') format('eot'), /* IE6-IE8 */
	     url('fishyfont.woff') format('woff'), /* Modern Browsers */
	     url('fishyfont.ttf')  format('truetype'), /* Safari, Android, iOS */
	     url('fishyfont.svg#svgFontName') format('svg'); /* Legacy iOS */
	}

Ralf Hermann is recommending it in an article on @font-face at Smashing Magazine.

Is it rock-solid? Looks like it. I would use it. But only IE9 RTM can seal the deal. Or not.
Stay tuned.

Best Practice For @Font-Face CSS Takes A Turn

Richard Fink — Mon, 31 Jan 2011 13:32:50 +0000

“Bulletproof ” is out, and “Mo’ Bulletproofer” is in.

In the last few days, major players on the web fonts scene – Kernest and Font Squirrel – have moved from Paul Irish’s Bulletproof @Font-Face syntax to Richard Fink’s Mo’ Bulletproofer syntax as the default.

Ethan Dunham, the developer behind Font Squirrel and Fontspring says:

Mo’ Bulletproofer is the only syntax that works across browsers including Android.
IE and Android both have buggy implementations and this format works around both of them.

Since I’m Richard Fink and this could just be my ego talking, here’s why Mo’ Bulletproofer is best practice going forward…

The Android local() Bug

Android has a bug that’s triggered by using the local() descriptor inside the @font-face declaration.

To clarify, the following non-standard code does not work on Android as it does in IE 6-8:

@font-face {
  font-family: 'somefont';
  src: url(somefont.eot);
  /* IE takes this font, Android doesn't. */
  src: local('3ix90a'), url(somefont.ttf) format('truetype');
  /* Android chokes on the local() descriptor and
    discards the entire @font-face declaration.
    No web fonts show up. */
   }

Unlike IE, Android doesn’t “look back” and take the font specified in the initial url reference.
This makes the “Bulletproof ” syntax unusable on Android.
The problem is described in a bug report filed by Google’s Paul Irish, originator of “Bulletproof ”.
It also includes this FYI:

This bug has also caused a workaround from the Google Font API team: http://code.google.com/apis/webfonts/
As a result they sniff and change the CSS they serve to Android 2.2 devices.

Android Is Too Big For This Problem To Go Ignored

There isn’t much choice here. Mo’ really is more bulletproof. Even if the Android problem didn’t exist, there are other solid reasons for using Mo’ , but Android is the kicker.
How big is the Android market? Well, in 2010 Android emerged as the single best selling mobile platform in the United States.
Andy Rubin, former Android CEO and current VP of Engineering at Google, reports that 300,000 Android devices are being activated every day.

Bulletproof Reported As Problematical On Linux, Too

Last week there was a pingback here at RW from WordPress developer Aaron James Young saying:

I use the Mo’ Bulletproof @font-face syntax, which I’ve found to have the best cross-browser compatibility.

Young spent considerable time hands-on, testing Linux based browsers, before coming to this conclusion.
(It seems GTK-Webkit and Konqueror also have problems with local()).

Don’t Use local() At All

The bottom line is that using local() at all is a bad practice. In Google Fonts Failing for Internet Explorer Users I wrote:

See Jonathan Snook’s post here, and this Typophile thread here for an in-depth explanation of why the local() descriptor should not be used to specify a locally installed font except in very special circumstances.

I now take part of that back: in the absence of being able to specify and query for a unique font version ID – as a matter of defensive coding – I can’t imagine a plausible scenario where using local() isn’t, in some way, asking for trouble.

Here’s the original post on Mo’ Bulletproofer. To be updated soon, after the next Beta of IE9 arrives for testing.

Update – Feb 3, 2011

Paul Irish has chimed in on this issue in the comments. See his roundup on full view, with web fonts, on this test page. Paul is reporting that IE9 downloads both the EOT file and the WOFF file using Mo’ Bulletproofer. His tests were performed in Platform Preview 7. Is it a bug or a flaw in Mo’ Bulletproofer that calls for the addition of Conditional Comments? (That would fix the problem and it’s likely that the page would already contain the necessary “less than” IE9 Conditional Comment tags, anyway.) Also, in yet a new turn, Ethan Dunham of Font Squirrel has chimed in with yet another syntax that looks quite promising. And clever, damn him. Stay tuned. Rumor has it that IE9 RC1 (or will it be an RTM?) is due out in just a few days. Will go hands-on with testing then.