Basically, your doubts are well founded: you don’t have very much reliable control over typography on the web.[0] Things like kerning.js are probably best regarded as admirable proofs of concept for future work.
You’re also right that webtypography.net is limited by our technology, but I think it’s also limited in its approach. ETS is a wonderful book,[1] but it’s really about print typography, and few of its practical guidelines are both possible and wise to apply directly to the web.
TypeKit is pretty good. Google Web Fonts is kind of a disaster from a fine typography viewpoint. Some of the fonts are nice for headlines, but last time I checked there isn’t a single text typeface which is reasonably attractive, kerned well, and has a real italic. Not one. There are some good decorative faces in there, but no drop-in Verdana replacement.
And text figures? Pffft. Small caps? Double pffft.
Here are some things that you have control over and are worth worrying about if you’re interested in web typography, in no particular order:
— Get past ASCII. Use real dashes, quotes, and apostrophes. Don’t put too much trust in automatic curly-izers, even when attached to reputable projects like Markdown.[2] And so on.
— Design on a grid. Set CSS’s line-height property by hand, or you’ll have interfering vertical rhythms. I like to set h1-6’s line-height to an even multiple of the base, but some people would consider this overkill. Set the sup and sub element’s line-heights to 0px or else they’ll screw with the leading. And so on.
— Think about how people actually read on screens. For example, on my screen, reading on full #ffffff is slightly uncomfortable after a while. People with wide screens will get ridiculously long lines if you don’t set a width to something sane like 60em. And so on.
0. Before someone says that this is a good thing because content and presentation should be separate, let me point out that we’re talking about presentation defaults here. No one wants to force everyone to see (or be screen-read) exactly the same thing. If we had some support for things like kerning in CSS, they would stay in CSS and be expected to degrade gracefully.
1. So good that I recommend it as an example of manual-writing to people with no interest in typography.
2. I’ve written about the problem of automatically curling apostrophes at http://rheme.net/apostrophes . In short, it’s hard to have a simple and fast algorithm that corrects the apostrophes/quotes in both:
She said "I like rock 'n' roll".
and
He said "I have a 'friend' who does too".
This is the kind of thing that only people who care about it will care about.
Basically, your doubts are well founded: you don’t have very much reliable control over typography on the web.[0] Things like kerning.js are probably best regarded as admirable proofs of concept for future work.
You’re also right that webtypography.net is limited by our technology, but I think it’s also limited in its approach. ETS is a wonderful book,[1] but it’s really about print typography, and few of its practical guidelines are both possible and wise to apply directly to the web.
TypeKit is pretty good. Google Web Fonts is kind of a disaster from a fine typography viewpoint. Some of the fonts are nice for headlines, but last time I checked there isn’t a single text typeface which is reasonably attractive, kerned well, and has a real italic. Not one. There are some good decorative faces in there, but no drop-in Verdana replacement.
And text figures? Pffft. Small caps? Double pffft.
Here are some things that you have control over and are worth worrying about if you’re interested in web typography, in no particular order:
— Get past ASCII. Use real dashes, quotes, and apostrophes. Don’t put too much trust in automatic curly-izers, even when attached to reputable projects like Markdown.[2] And so on.
— Design on a grid. Set CSS’s line-height property by hand, or you’ll have interfering vertical rhythms. I like to set h1-6’s line-height to an even multiple of the base, but some people would consider this overkill. Set the sup and sub element’s line-heights to 0px or else they’ll screw with the leading. And so on.
— Think about how people actually read on screens. For example, on my screen, reading on full #ffffff is slightly uncomfortable after a while. People with wide screens will get ridiculously long lines if you don’t set a width to something sane like 60em. And so on.
0. Before someone says that this is a good thing because content and presentation should be separate, let me point out that we’re talking about presentation defaults here. No one wants to force everyone to see (or be screen-read) exactly the same thing. If we had some support for things like kerning in CSS, they would stay in CSS and be expected to degrade gracefully.
1. So good that I recommend it as an example of manual-writing to people with no interest in typography.
2. I’ve written about the problem of automatically curling apostrophes at http://rheme.net/apostrophes . In short, it’s hard to have a simple and fast algorithm that corrects the apostrophes/quotes in both:
and This is the kind of thing that only people who care about it will care about.