May 20, 2010 2 replies

Google enters the @font-face business

Google Font Directory

Google is throwing its own hat into the web fonts ring with the Google Font Directory and the Google Font API. While it appears it doesn’t have any partnerships with the big names in typography like TypeKit does, just a handful of open fonts, it does have a partnership with TypeKit itself (as you’ll see below).

How the Google Font API works

Once you pick a font, you can embed it on a webpage by grabbing code that looks like this:

<link href='http://fonts.googleapis.com/css?family=Josefin+Sans+Std+Light' rel='stylesheet' type='text/css'>

And use it in your stylesheet like this:

h1 { font-family: 'Josefin Sans Std Light', arial, serif; }

You can also use other fonts using the WebFont Loader, which is a JavaScript library developed by Google and TypeKit.

Bane or Boon?

Google Font API

Although I won’t be ditching Font Squirrel anytime soon, one great thing about this new development is that the fonts are hosted on the most reliable servers in the world, just like the different JavaScript libraries are. The even greater thing is that this is Google, one of the strongest forces on the Web, is placing a stake another aspect of web standards.

Of course those things are scary at the same time. Google can just pick any endeavor under the sun, spend resources on it, and possibly dominate, if not dictate the market in no time. It may not get the purist designer types on board, since Google doesn’t exactly have the best reputation for great design, and its presentation has a bit of a developer slant, but it knows its web design technologies well. And in the case of web standards, where new practices are being adopted and old browsers are being discarded at a snail’s pace, Google’s massive resources and influence can only do well to speed things up.

May 11, 2010 one reply

WebKit: One browser engine to rule them all?

WebKit logo

Right now, so many major players in the web browsing space have turned to the WebKit project for its rendering needs—

  • Apple: Safari
  • Google: Chrome
  • Nokia: Symbian web browser for S60
  • Google: Android web browser
  • Research In Motion: BlackBerry web browser
  • and more

—that one has to wonder if web browsers should just stop running on their own and agree to just merge, possibly under WebKit, since it seems to be so popular across the board. To be clear, if Mozilla’s Gecko renderer had the same track record, I’d say the same thing.

It’s less a matter of killing healthy competition and innovation among vendors, more about eliminating the headache of rendering differences. People can probably file away all the browser bugs and inconsistencies across browsers and their various versions in a full encyclopedia set. (IE6 would take up at least a couple of volumes.) This tedious aspect of front-end development could be greatly reduced if all these browsers adopted the same rendering kit. Then the vendors can focus on improving and innovating in other aspects, like what Google did with its JavaScript V8 engine.

Mozilla can enjoy more time expanding its already large and loyal userbase, working on Labs products like Bespin and Weave, pushing for the WOFF web font format, and so on.

One can argue that if we should be able to choose browsers, then the same can be said for underlying rendering engines, and accept the differences as a a consequence of the freedom to choose. But does a consumer of the Web need to choose which rendering engine he prefers? Or are the differences something we can finally do without?

I, for one, would be thrilled if we didn’t have to worry whether websites looked the same in every browser, and just focus on making websites look and behave the best they can. And I’m pretty sure ordinary users don’t even think about rendering differences.

April 20, 2010 say something

The designer-comic artist hybrid (7 strips you should be following)

Blame it on the need to express oneself in as many avenues possible, or the tendency for this community to navel-gaze out of narcissism or frustration, but you can’t deny how comic strips are a brilliant outlet for these designers. Each carries a different subject, sense of humor, and illustration style that you’ll want to subscribe to all of them.

Brad Colbow: The Brads

Test How Your Site Looks on the iPad

Brad’s also been tapped to create more informative strips such as Learning About Contrast in Design and Misunderstanding Markup: XHTML 2/HTML 5.

Kyle Weems: CSS Squirrel

Push To Dispense Free Cheese

I’ve mentioned CSS Squirrel when he announced his branching out to podcasting, but poking fun at the latest industry developments and insider info is where he shines.

N.C. Winters: Freelance Freedom

The Design Process

NC goes through the ups and downs of freelancing at Freelance Switch’s Freelance Freedom.

Business Guys on Business Trips

Client De-briefing

BGOBT tells the most awful office tales in detailed narrations but minimal line art.

Matthew Inman: The Oatmeal

How a Web Design Goes Straight to Hell

The man behind Mingle2 and SEOmoz, Matthew has gone on to create humorous quizzes and infographic-style comics at the very viral The Oatmeal.

Phil Thompson: The FrontEnders

Should Web Designers Code HTML?

Phil does a front-end spin on the British soap The Eastenders.

Ricardo Gimenes: Behind the Websites

Front-End design conference

Ricardo creates a fleet of colorful characters to represent different websites, and now makes strips for Smashing Magazine’s The Smashing Cartoons.

/* */