log

January 31, 2010

All you never wanted to know about browser generic font family fallbacks

I recently needed to know exactly what fonts desktop browsers use in the case of generic font families. Getting this info for multiple platforms and languages is actually pretty difficult unless you enjoy sifting through several different source trees in several different source viewers.

Locales are generally expressed as two-letter language codes (‘en’ for English, ‘ar’ for Arabic), sometimes with an additional two-letter code for region or derivative (‘en-GB’ for British English, ‘zh-CN’ for Simplified Chinese). A good reference is the the Plesk Locale Codes doc.

Skip to the matrix if you’re just after en-US defaults.

Mozilla

Probably the easiest to read is Mozilla’s prefs file, simply because it’s all in one place. It’s grouped into platform then locale. For example, pref("font.name.serif.ja", "?? ???") specifies the serif font for Japanese.

Note that these may not be the defaults in all Mozilla-derived browsers

  • Windows fonts
  • Mac fonts
  • OS/2 fonts (also see note in source about name remapping which may affect you).
  • BeOS fonts include only basic mapping to a generic family (remapped by the OS to a locale-specific font?).
  • Unix/Linux fonts include only basic mapping to a generic font (remapped by the OS to a locale-specific or system-preference font?) This could mean a variety of defaults depending on the unix derivative, distro, window system, graphical environment and god knows what else (please correct me if I’m wrong).

Chrome

Chrome breaks down font defaults into a generic platform file then specific override files. They follow a naming convention using the locale codes above. Files are in XML, thus needlessly verbose and hard to skim. Look for <message name="IDS_SERIF_FONT_FAMILY" use_name_for_id="true">Times New Roman</message> at the bottom of generic files and <translation id="IDS_SERIF_FONT_FAMILY">Tahoma</translation> in the overrides.

Safari/Webkit

Unlike the browsers above, Safari itself isn’t open source and so it’s hard to get a definitive list outside of Western locales. Webkit (the underlying engine that is open source) has these en-US defaults hard coded:

Stating the obvious but relevant: Webkit has been ported to a legion of devices and platforms now, each with their own frontend capable of changing the default generic fonts (especially in the case of mobile where only one font may be available). Firefox for Windows Mobile and Opera Mini are in the same boat. Determining the default generic fonts for these platforms is arguably pointless.

Opera

This one’s purely from observation of a local install on an ‘en-AU’ Windows machine (likely identical to any other ‘en’ install). I’m unable to check the defaults for any other platform atm.

  • Serif: Times New Roman
  • Sans-serif: Arial
  • Monospace: Courier New
  • Cursive: Comic Sans MS
  • Fantasy: Arial

Note that the original 10.0 release had a bug that did funky stuff to cursive and fantasy. Fixed in 10.1.

Internet Explorer

The truly problematic one. I don’t have the first idea how to gather this information without access to the regional build and OS. Information is welcome! On my ‘en-AU’ WinXP machine IE6 through 8 default to:

  • Serif: Times New Roman
  • Sans-serif: Arial
  • Monospace: Courier New
  • Cursive: Comic Sans MS
  • Fantasy: Algerian

A quick font matrix for en-US

Browsers across the top header row, and font families down the first column. Where a font differs from other browsers, it has been highlighted and bolded.

Windows

Mozilla Safari Chrome Opera IE
Serif times new roman times new roman times new roman times new roman times new roman
Sans-serif arial arial arial arial arial
Monospace courier new courier new courier new courier new courier new
Cursive comic sans ms comic sans ms comic sans ms comic sans ms comic sans ms
Fantasy microsoft sans serif impact comic sans ms arial algerian

Mac

Mozilla Safari Chrome
Serif times times times
Sans-serif helvetica helvetica helvetica
Monospace courier courier courier
Cursive apple chancery apple chancery apple chancery
Fantasy papyrus papyrus papyrus

No one uses Fantasy apparently, and I can’t help but think that Apple used Comic Sans MS twice as a statement about the Windows aesthetic.

If you’re a browser dev with more info or if your results conflict, please let me know.

posted by Andrew

January 30, 2010

Another demo layout: Difference

Demo: A difference of layoutAlthough it’s pretty finished, this one’s been sitting static since last October; TAFE resumed and didn’t get around to posting it. I have some unique JS and dropdown menus to include before I update it again. I’ll try to post about the JS later since it’ll be reusable and of general interest to other designers.

posted by Andrew

January 29, 2010

Haiku for the moment

apple apologists
sincerest astroturfers
where is my shotgun?

posted by Andrew

Ugh

It’s hard to read something so incredibly naïve and not want to comment.

You can browse the Internet, or check your mail, or take notes, or listen to music, but when you’re out of little buttons to press then you’re out of things to do.

Wow.

Some of the biggest complaints come from programmers that say the closed system means people won’t be able to satisfy their computer curiosities. To which I again say: Good! Then they’ll have to satisfy their curiosities about emotional maturity and social interaction and possibly even thinking about making the world a better place.

Wow.

But however will children learn how to program? Simple: We will make them applications that teach them how to program. Every kid wants to make video games and Google, so it’s not like having a closed system will make them forget that such things are possible.

Wow.

(I reach this part in the post when I start wondering whether it’s a masterfully disguised parody piece, and I check some other posts. It seems not.)

And because the iPad is so elegant and makes elegance so relatively easy, these apps will be elegant. We won’t get a row of advanced text editors too complex for people to understand.

Wow.

The open systems will still exist. Certainly people with certain aptitudes will always prefer something that puts the power in their hands. But they don’t have to be the default. Not when those open systems risk confusing and alienating people who just want to check their mail. We lose nothing by having closed systems.

Wow.

I’m not dedicating extensive time to rebut this, but I have to wonder which browser Rory is using, which blogging system he’s posting with, which web server delivers his writing, which language specs define the structure & style of his site and which operating system got him this far. Chances are that almost all of them are open in some way, whether Libre or Gratis or extension level or UI level or API level or hardware level. We got this far because of openness and programmability, sometimes pushing down extensive technological and economic barriers raised by closed-ecosystem builders to do so.

Being pissed off because you don’t grok the programming that makes your trinkets work is no reason to slap the originators in the face and generalise them into a group with “obsessive-compulsive problems mixed with an antisocial attitude”.

(It may however be time to analyse your own apparently similar issues.)

When technology seems rosy it’s a reason to push harder for the next exponential improvement, not grab the nearest elitist-woven comfort blanket and call it a day.

Posts like these are the ones we look back at in ten years and cringe. I hope so anyway.

posted by Andrew

January 25, 2010

HTML 5 <video>

Awesome post by Christopher Blizzard on why Mozilla won’t (rightly) support H.264.

posted by Andrew

January 13, 2010

In the absence of JavaScript

Winamp’s download page demonstrates why web developers shouldn’t rely on JavaScript. With the advent of NoScript and related tools a single external script makes this page useless.

Winamp's download page, 2010/01/13

posted by Andrew