I have deactivate webfonts in Firefox and have a fonts.conf that rewrites nearly all fonts to the same 3 fonts. Many, many blogs use webfonts to look different, which might be something the blog author wants, but I don’t. I just want to read.
What eventually led me to completely blocking webfonts were the rendering issues. It seems the webfonts are usually tested on OS X and maybe Windows. They nearly always looked broken for me (bad kerning, weird aliasing, just plain ugly).
I hope that at least non-designers will stop using webfonts on their pages.
What eventually led me to completely blocking webfonts were the rendering issues. It seems the webfonts are usually tested on OS X and maybe Windows. They nearly always looked broken for me (bad kerning, weird aliasing, just plain ugly).
That’s interesting. I’ve always had good experiences with webfonts on linux, Windows has always had rendering issues for me. But that’s true for my experience with fonts in general.
It doesn’t necessarily change the article’s point (since we’re in a quite different place nowadays), but historically I don’t think this is true:
Ask yourself this: if network bandwidth had been able to support the requisite file sizes when the web began, wouldn’t fonts sent from the server have been greatly preferred over system fonts?
I don’t think that would have been the case, no. The original web was much more of a “hypertext” concept than an “online publishing” concept. Relatively simple semantic markup was there to indicate document structure: which parts of the document were links, top-level headers, secondary headers, etc., with the expectation that the client would render these in a way suitable for its context. Not only was the expectation that the client would choose its own fonts, but even that it would choose between things like whether to use bold or italic for emphasis, choosing how to format section headers, etc.
Where I think this might have been true though is around the time font styling support was added to HTML (which was, I believe, with HTML 3). If networks had been faster and font packaging/licensing were sorted out at the time, this might’ve been introduced together with webfonts, rather than what was actually introduced, a tag where a webpage could set fonts by name, which would work if the client happened to have a font with that name installed. Which puts you in a weird situation where you have to guess what fonts the client might have installed (and what their names are!): the webpage is setting something on the client that it has no real knowledge of or control over, except by assuming things about what kinds of client systems are most widespread. I see why designers don’t much like that situation, since it’s an awkward halfway house. The original semantic-hypertext idea is coherent, and the HTML/CSS online-publishing idea we’re converging on is also coherent, but there was an awkward period with a really half-assed mix between hypertext and presentation elements, like the <font> tag.
I have deactivate webfonts in Firefox and have a fonts.conf that rewrites nearly all fonts to the same 3 fonts. Many, many blogs use webfonts to look different, which might be something the blog author wants, but I don’t. I just want to read.
What eventually led me to completely blocking webfonts were the rendering issues. It seems the webfonts are usually tested on OS X and maybe Windows. They nearly always looked broken for me (bad kerning, weird aliasing, just plain ugly).
I hope that at least non-designers will stop using webfonts on their pages.
That’s interesting. I’ve always had good experiences with webfonts on linux, Windows has always had rendering issues for me. But that’s true for my experience with fonts in general.
It doesn’t necessarily change the article’s point (since we’re in a quite different place nowadays), but historically I don’t think this is true:
I don’t think that would have been the case, no. The original web was much more of a “hypertext” concept than an “online publishing” concept. Relatively simple semantic markup was there to indicate document structure: which parts of the document were links, top-level headers, secondary headers, etc., with the expectation that the client would render these in a way suitable for its context. Not only was the expectation that the client would choose its own fonts, but even that it would choose between things like whether to use bold or italic for emphasis, choosing how to format section headers, etc.
Where I think this might have been true though is around the time font styling support was added to HTML (which was, I believe, with HTML 3). If networks had been faster and font packaging/licensing were sorted out at the time, this might’ve been introduced together with webfonts, rather than what was actually introduced, a tag where a webpage could set fonts by name, which would work if the client happened to have a font with that name installed. Which puts you in a weird situation where you have to guess what fonts the client might have installed (and what their names are!): the webpage is setting something on the client that it has no real knowledge of or control over, except by assuming things about what kinds of client systems are most widespread. I see why designers don’t much like that situation, since it’s an awkward halfway house. The original semantic-hypertext idea is coherent, and the HTML/CSS online-publishing idea we’re converging on is also coherent, but there was an awkward period with a really half-assed mix between hypertext and presentation elements, like the
<font>tag.