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?

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.

Originally posted on May 20, 2010 @ 10:37 pm

Remember my complaint about all the CSS3 syntaxes differing from one browser to another? It’s now addressed with CSS3 Please, a jQuery-based, in-browser editor that replaces multiple attribute values of the more complicated CSS3 syntaxes (from border-radius to rgba to @font-face) all at the same time, so you don’t have to.

In addition to syncing and normalizing changes across the necessary properties, it also sneaks in IE support for a few features via IE filters. Right now it helps you write the rules for: border-radius, box-shadow, linear-gradients, rotation and @font-face. A few more transforms like skew and scale are on their way, stay tuned.

You can preview your code on the box at the right side by toggling it on and off. When you’re done, click on the clipboard icon to copy the code.

This is a smart solution to a growing problem. However, even though I’m thoroughly grateful for this tool, I still want to axe the real problem, which is the inconsistent browser syntax. It’s unreasonable for a programming language to have redundant code, and while CSS isn’t really one, it’s still code. We’re still supposed to pride ourselves with efficiency, conciseness, and standards with any kind of code. We like to kick IE for constantly breaking standards; should we tolerate the same thing for other browsers just because they’re implementing cutting edge features?

Originally posted on March 12, 2010 @ 7:49 pm

It’s a disappointing day when you find a single serving site that generates the comprehensive syntax for the border-radius property, aptly named border-radius.com. Because not all browsers (and browser versions) support the latest and greatest things CSS3 can do, one has to resort to browser targeting yet again. Only this time, one browser’s syntax is different from another browser’s, and becomes a chore to write CSS for each.

There’s a pretty obvious explanation for the existence of browser-specific properties from SitePoint:

Vendors—browser makers—are free to implement extensions to the CSS specifications that, in most cases, are proprietary to their browser. They may do this for a number of reasons, such as adding new features for users, or for experiments and debugging. Most often, though, the extensions are used to release and test browser features that have been developed in the preparation of W3C drafts that have not yet reached Candidate Recommendation status—the extensions allow these new properties to be widely tested before they become available as standard CSS properties.

So for starters, the browser-specific CSS has prefixes like:

• -moz: Gecko-based browsers like Firefox
• -webkit: WebKit-based browsers like Safari and Chrome
• -ms: Internet Explorer
• -o: Opera
• -khtml: Konqueror

(The complete table is listed at the W3C.) That’s fine, but what I don’t get is why the syntax following the prefix isn’t always the same as the standard CSS syntax. The border-radius property is just one example, which is peanuts compared to the gradients syntax. Compare:

-webkit-gradient(
    linear,
    left bottom,
    left top,
    color-stop(0, rgb(0,10,148)),
    color-stop(1, rgb(45,58,246))
)
-moz-linear-gradient(
    center bottom,
    rgb(0,10,148) 0%,
    rgb(45,58,246) 100%
)

Sure, we can turn to generators like WestCiv’s and Damien Galarza’s—and we’ll probably be increasingly dependent on them in the future as CSS capabilities and their corresponding syntaxes grow more complex. But why must browser vendors insist on that when it only multiplies the code and maintenance necessary? Does it have to do with the way their engines parse the code, or something less significant?

Originally posted on March 2, 2010 @ 9:52 pm

Andy Clarke of For A Beautiful Web has presented a stylesheet for the web browser we haven’t been able to push off the provebial cliff: Internet Explorer 6.

When I asked myself why people visit my sites, and the ones that I make for other people, the answer was always “for the content”. Content that is almost always written words and that means type.

That is why I’m now advocating to my clients (and to you), that where feasible, not to waste hours in time and a client’s money on lengthy workarounds in an unnecessary attempt at cross-browser perfection. Instead, you and I should provide simple but effectively designed HTML elements. This means just great typography for headings, paragraphs, quotations, lists, tables and forms and no styling of layout.

But this idea is not new; this Universal IE6 CSS file contains just enough rules for a practically unstyled but easy to navigate website. You’re basically giving websites loaded in a low-fi browser a low-fi experience. Examples here, here, and here.

Despite its waning popularity, we seem to have amassed a whole buffet of solutions to the shortcomings of IE6, ranging from the hostile upgrade messages and campaigns to the subtle conditional stylesheets and scripts.

I can just imagine someone creating one of those personality quizzes out of this whole debacle: which IE6 compatibility fix are you? There’s an idea.

But really, dealing with IE6 and somesuch boils down to principle and circumstance. Can your clients and your conscience accept barely recognizable version of their sites in twentysomething percent of their audience? Is your sanity more precious than squishing mysterious bugs? Or do you feel like throwing some humor in?

Let me know if someone’s actually made a personality quiz about this; I’d love to take it.

Originally posted on May 21, 2009 @ 11:24 pm

Harry Roberts a.k.a. CSS Wizardry tweeted a certain tutorial by CSS Aid (page is dead now), which was enclosed with four little words (“Good lord, wrong much?”) that echoed such alarming levels of horror and shock (considering he tweets about poor examples of HTML/CSS code everyday), that I had to check it out.

First, the tutorial was entitled “Tables Without Tables”. If that doesn’t trigger warning bells in your head, then consider the opening paragraph:

It’s the year 2009, CSS rendering has vastly improved from when it was released, so there is no reason for any website to use tables as layouts. Although you can ditch the table tag when it comes to layouts, you may someday need to use it for what it was made for…or do you? I am going to show you an easy way to make a table with a simple unordered list.

No. Just no. Yes, <table>-based layouts are considered wrong because HTML is supposed to properly represent data. Lists should be lists. Tables should be tables. Layouts that look like tables (grids) can be done in CSS. That’s semantics, the core principle of web standards.

But avoiding the use of <table>s at all costs is no better. Perhaps it’s even worse, since it demonstrates not only ignorance but false expertise, feigning arrogance over an HTML element that has been shuddered at because of its misuse and abuse.

The page has gone down in between the time that I read the tweet and wrote this post. Fortunately the forum thread that seems to be the source of the link is still up, and shows us the author’s reasoning for writing the tutorial. Take post #7:

Because I hate the <table> tag

Is this the extreme dark side of web standards, where we’ve been conditioned to hate <table>s so much that we can’t even think to use them for what they were meant for anymore? A sad, sad turn for us all.

By post #15 he’s already backed down and promises not to use the experiment for real-life cases, but this summarizes things nicely:

It’s a pointless experiment though. It’d be like experimenting making a house out of tampons. Doable but just plain wrong.

It’s bad enough that we have to deal with preaching proper web standards, dropping crusty old browsers from, and adding newfangled technologies to our web design arsenal. Let’s not get sidetracked by punishing HTML elements by twising them into things they weren’t meant to be.

Originally posted on August 20, 2009 @ 4:56 pm