Bug 1007629 returned to the classic system fonts. But our goal is to be consistent across all platforms. Here are the issues raised in bug 1007629 : - System conformity The goal of project chameleon is to unify the content styling across platforms, including typography. - Rendering of fonts I tend to agree with this, Clear Sans looked horrible on Windows. But it doesn't seem like the case for Fira Sans, see demo here : http://dev.carrois.com/fira-3-1/ - Performance I did notice a 1 second freeze sometimes when opening the pref page, but since we'll use compressed fonts for Fira Sans, that shouldn't be a problem anymore

Note that we got issues with localization since some charaters were not supported by Fira Sans : see bug 992650

(In reply to Tim Nguyen [:ntim] from comment #0) > Bug 1007629 returned to the classic system fonts. But our goal is to be > consistent across all platforms. > > Here are the issues raised in bug 1007629 : > - System conformity > The goal of project chameleon is to unify the content styling across > platforms, including typography. But this isn't "content", IMO: despite being called "inContent prefs", this is browser UI. So I don't think "content styling" is relevant to it. The "inContent" aspect is an implementation detail that shouldn't determine the user experience. > > - Rendering of fonts > I tend to agree with this, Clear Sans looked horrible on Windows. But it > doesn't seem like the case for Fira Sans, see demo here : > http://dev.carrois.com/fira-3-1/ Does it render well across all versions from XP to Win8, and with the various system options for font rendering/smoothing? (This is a genuine question: I haven't tried to look at it across all the relevant environments. The demo page above seems to insist on using grayscale AA on my WinXP VM, regardless of how I set the system options; I don't know if that's a Firefox bug, failing to respect the settings, or something about how the page is styled.) > > - Performance > I did notice a 1 second freeze sometimes when opening the pref page, but > since we'll use compressed fonts for Fira Sans, that shouldn't be a problem > anymore I'm not sure what you mean here. Using compressed fonts isn't likely to avoid a potential pause due to activating the font; it may be a smaller file, but OTOH it then has to be decompressed on the fly before we can use it, so it might actually be MORE expensive to initialize.

(In reply to Jonathan Kew (:jfkthame) from comment #2) > (In reply to Tim Nguyen [:ntim] from comment #0) > > Bug 1007629 returned to the classic system fonts. But our goal is to be > > consistent across all platforms. > > > > Here are the issues raised in bug 1007629 : > > - System conformity > > The goal of project chameleon is to unify the content styling across > > platforms, including typography. > > But this isn't "content", IMO: despite being called "inContent prefs", this > is browser UI. So I don't think "content styling" is relevant to it. The > "inContent" aspect is an implementation detail that shouldn't determine the > user experience. UX defined in bug 1014208 that in-Content UI should use Fira Sans for all platforms. > > > > - Rendering of fonts > > I tend to agree with this, Clear Sans looked horrible on Windows. But it > > doesn't seem like the case for Fira Sans, see demo here : > > http://dev.carrois.com/fira-3-1/ > > Does it render well across all versions from XP to Win8, and with the > various system options for font rendering/smoothing? > > (This is a genuine question: I haven't tried to look at it across all the > relevant environments. The demo page above seems to insist on using > grayscale AA on my WinXP VM, regardless of how I set the system options; I > don't know if that's a Firefox bug, failing to respect the settings, or > something about how the page is styled.) Not sure about this. But seems to look good on Windows 7/8 and OSX. > > > > - Performance > > I did notice a 1 second freeze sometimes when opening the pref page, but > > since we'll use compressed fonts for Fira Sans, that shouldn't be a problem > > anymore > > I'm not sure what you mean here. Using compressed fonts isn't likely to > avoid a potential pause due to activating the font; it may be a smaller > file, but OTOH it then has to be decompressed on the fly before we can use > it, so it might actually be MORE expensive to initialize. Well, we could install Fira Sans on the computer for each user, it would then avoid loading it from the @font-face rule.

(In reply to Tim Nguyen [:ntim] from comment #3) > (In reply to Jonathan Kew (:jfkthame) from comment #2) > > (In reply to Tim Nguyen [:ntim] from comment #0) > > > Bug 1007629 returned to the classic system fonts. But our goal is to be > > > consistent across all platforms. > > > > > > Here are the issues raised in bug 1007629 : > > > - System conformity > > > The goal of project chameleon is to unify the content styling across > > > platforms, including typography. > > > > But this isn't "content", IMO: despite being called "inContent prefs", this > > is browser UI. So I don't think "content styling" is relevant to it. The > > "inContent" aspect is an implementation detail that shouldn't determine the > > user experience. > UX defined in bug 1014208 that in-Content UI should use Fira Sans for all > platforms. UX is a group of rational people whose decisions can be questioned. Jonathan just did that and your response isn't really helpful. FWIW, I can see how putting UI in the content area where users usually see web content allows us to drop platform defaults, but that doesn't mean we should do that in every possible way.