It wasn’t that long ago that we saw the same five typefaces over and over as we surfed the web. If you’ve been designing websites for a while, or are a long time web surfer, you probably remember the days of limited typography options. Those were the fonts that were most likely on a user’s machine, so they were considered to be “web-safe” since the majority of users could view the website as intended. If you open up a stylesheet from an older site you will likely find Arial, Georgia, Times New Roman, Trebuchet MS, and/or Verdana. For a user to see the font that was intended by the designer, it was necessary that they had that available on their computer. In the early days of the web, we were stuck with web safe options, which were very limiting. They do not work well in paragraphs and should be used in situations where they appear in a large block. Due to the limited selection of fonts available on many mobile platforms (and my unfamiliarity with many of them) I’ve added more options to the test page.Display typefaces are meant to be shown in headings and other prominent areas so they stand out. Since I first wrote this I’ve had the chance to test the font stack on a decent selection of mobile devices, so I’ve updated the table to show those findings. So here’s the font stack: font-family: Helmet, Freesans, sans-serif Īnd here’s a table of what you can expect to see as a result: Update I’ve been in contact with the Opera for Mac team about it, and they’ve said they’ll change their sans-serif output to Helvetica or Arial within the next couple of releases to benefit platform consistency. We can reign in Linux by specifying a couple of open-source Helvetica derivatives that are installed on all the main Linux distros Helmet & Freesans. The only edgecases are Opera for Mac (which interprets sans-serif as Lucida Grande) and Linux browsers (which seem to pick an arbitrary font from a hat, but then as they don’t have Helvetica Neue or Arial installed this was how they were behaving previously anyway).
Turns out that Wikipedia simply specify the following: font-family: sans-serif Ī bit of testing revealed that for the most part, just specifying sans-serif will give Windows users Arial and Mac users Helvetica. As I was mid Wikipedia-ing some background information for the problem, I noticed that Wikipedia itself renders in Helvetica (on a Mac) yet doesn’t have the bug. Either way, both bugs occur in modern browsers & render the page unreadable, which is enough reason to look into a different solution. These are the bugs I’ve consistently reproduced, I get reports of others but I haven’t managed to replicate them myself. This in combination with various CSS styles triggers Webkit into having a bit of a breakdown. The same agencies that commission websites by the hundred and really care if things look broken.Īnother bug hits Windows users with a pirated version of Helvetica Neue installed on their system.
If you’re just looking at raw numbers this issue is quite rare, but unfortunately there’s a pretty notable demographic where this setup comes as default on every desk - large design agencies. Cool display font, but its almost invisible when set in for text onscreen. On these machines Safari renders Helvetica Neue Bold as Helvetica Neue Bold Outline. The first issue affects pre-Snow Leopard Macs with Adobe’s extended font pack installed. But recently I’ve stress tested this font stack a bit more (hey there BBC GEL) and found a few problems with that have caused me to change up my approach. I don’t know who invented the technique, but you see it recommended everywhere and I’ve used it loads myself. For the last few years having a CSS font stack that specifies Helvetica Neue followed by Arial has been the most popular way to do it, with the aim of presenting Mac users with Helvetica Neue (which is installed on every Mac) whilst Windows users see Arial (a Helvetica variant optimised for Windows). We all love a bit of Helvetica, especially on websites.
0 kommentar(er)
