The estimable Kathleen Tinkel, éminence grise of graphic-design and desktop-publishing criticism, wrote me the other week to say she’d seen a bizarre character-encoding problem in the headings of this blog. I checked (thoroughly, of course) and told her I didn’t see anything.
I’m sure she took that at face value and didn’t want to trouble me anymore. So she posted her complaints to a rather unrelated site, Desktop Publishing Forum.
She admits that she had, for some reason, deactivated one font after another in her system. Even though 30 cursive or script fonts are defined for h1 along with the required fallback of cursive, there isn’t a match on her system. That’s a fault with her system, which should map the generic cursive.
To respond to the buzzing gnats:
-
Honestly, I have never ever seen such a long list of fonts to choose from but I think your browser is chancing on one that happens to have those mis-fitting glyphs on the code points – or it happens to not have glyphs for those letters at all, and they are picked from some other font in the list or wherever the browser goes when it hits an empty box in the font. […]
I can easily understand wanting to have people see fancy (in this case, “cursive”) headlines. Unfortunately, the fonts in the CSS list are not widely distributed, as David noted.
I could imagine that, too. But as the list of cursive fonts was the result of lots of research into what is actually installed into Mac, Windows, and Linux systems (in that order), if those fonts are there then they are professionally-developed fonts.
In any event, a browser that shows the wrong glyph is in noncompliance with the CSS spec:
To deal with the problem that a single font may not contain glyphs to display all the characters in a document, or that not all fonts are available on all systems, this property allows authors to specify a list of fonts, all of the same style and size, that are tried in sequence to see if they contain a glyph for a certain character.
-
Whatever this is, I would suggest that it is unsuccessful in terms of accessibility!
Yeah, thanks. It has no impact on disabled people. Even if it does, I’m allowed a tiny bit of leeway in giant fonts on my own blog.
-
Not only a long list of alternatives, but not very popular fonts, at that.
Popular cursive fonts are the ones used by tacky people. You know, like Palace Script on a “limousine” service run by an émigré Russian gangster.
You only need one (or the default “cursive”) but I suspect Joe may have forgotten to test that headline with each individual font in that long list. […] So that’s the lesson here: lists of font choices are fine – even long lists – but test your document with each of them.
Over my dead body.
And on different browsers.
Ditto.
-
In my case, I found that Safari and Firefox took different approaches about what to do. Safari was happy to try to work with an expert set (fractions, ligatures); Firefox was more skeptical.
“Expert set” is a rather antiquated 1990s concept. The browser must search for a Unicode font or display a specified glyph for its absence. (The approach taken by Lynx is rather different.)
Now, what nobody has bothered to mention is that the same bug I discovered before in the CSS validator remains unfixed. The validator still claims there are too many fonts in the list. There is no maximum number of fonts in the specification. In addition, both IE6 and IE7 display Verdana instead of any cursive font even though appropriate Windows fonts are specified.
If you have a problem with me, come to me, not to a hive of strangers.