I can't think of any mb as long as you like the look. You'll essentially get system font defaults across the board if you do this, which means Helvetica(ish- depending on version) on the Mac and Arial on the PC. I think on Android you'll get roboto and their Apple's SF font on iOS.

Seems like it'd be hard to design for though, considering the font switching. Maybe on a predominately text site it would be OK.

That said, since AMP supports loading of external font files (although from limited sources), I would instead make AMP's requirements your baseline. That gives you external font capability and consistency in appearance across devices, but ensures good speed.

The Apple San Francisco font looks very nice, as does Roboto. I've never been a fan of Arial because it's a narrow font (I've always preferred Verdana) but I know people enjoy Arial because you can squeeze more words onto a page. Arial's not a bad font.

Feeling comfortable with a site is important for conversions and trust building. So another upside I see to this is that if the site font matches the system font of the site visitor's device that there might be a subconscious familiarity extended to the site.

In Firefox Options >> Content >> Fonts and Colors >> Advanced you can uncheck "allow websites to choose their own font" and get an idea of how this would look.

why not just go font-less, and not declare a font?

Hurrah, hurrah, I'm all for it. Or pick some fonts that everyone has, like {font-family: Arial, sans-serif;} or {font-family: Courier, monospace;} always with "serif" or "sans-serif" or "monospace" as the fallback. (There are actually five generic families, but you do not want to mess with "cursive" or "fantasy" unless you know exactly what you are doing. Named fonts do not need quotation marks unless they contain a space.) There used to be an excellent website with numbers and examples on font stack building, but it seems to have disappeared :(

The one drawback to "serif" is that all too many browsers default to some version of Times, which is frankly a crummy font and has an exceptionally small x-height, something you need to keep in mind when specifying sizes. (otoh you can safely assume that the average sans-serif font has a bigger x-height than the average serif font, so you can set your sizes accordingly)

While you're at it, PLEASE do not specifiy a numerical point size. Work outward from the user's default, which is your 100%. If I can't read your site because the print is too small, I am very unlikely to stick around. Why the ### should I, the visitor, have to mess with my View settings on every new site?

Oh, and... You don't have to use third-party fonts, y'know. You can also embed fonts that live on your own server. Always include a {local(blahblah)} option for users who happen to have the specified font already, so they don't have to download.

I've been working with this kind of fontlessness for some time now and have not seen (or had negative feedback) anywhere. It seemed to make (common) sense to me. ;)

When it come to typography everyone thinks they are a designer. Some are, but the vast majority have no clue!

Stick with the standard user installed fonts and you can't mess up too badly, nor do you have to worry about a third party font source not being available for x period of time. You won't have additional overhead on your site download. More importantly, you can be pretty certain those fonts actually DO exists under ordinary OS installs.

There is variety in web safe fonts, just not for the fantasy side of things. One place to start is: [w3schools.com...]

With the exception of a few of my clients, I have always been fontless for 17 years going with the basic Arial,Helvetica,Verdana,sans-serif or Times,"Times New Roman",serif. I have had no complaints and have never seen a problem. And, if I need to draw on an external font, I try to download the files to the server rather than drawing from a third party, e.g. Google fonts.

I'll add Georgia to the serif list above, with Book Antigua as fall back, then New Times Roman. Georgia, in my view, is a bit more attractive than Times Roman with a larger x-height.

Personally, I over ride all sites in my PERSONAL browser to Georgia-- used to be Cooper BT (even larger x-height!) until UTF-8 became more important. I have my desired font size specified, etc. There's a side benefit in download speed in that the browser ignores any font instructions and things move along at a smart pace. Pretty sure I'm not the only one doing this. :)

For when I ABSOLUTELY must have a fancy font visible I do that as a GRAPHIC (which can't be overridden) with alt-text that says what it is.

Meant to add: For several clients, over the years, fonts have been installed at their server level and considered a cost of doing business. If at all possible I always recommend avoiding third parties for site display.

I removed all fonts from the style sheets and simply specified "sans" which causes the site to default to the browser's native default font.

body {
font-family: Sans-Serif;
}

The first feedback I received, without any hints given by me as to what changed, was that it was noticed right away that the text was easier to read. So that's a win!

Hey mb, you see this? Back in the old days [awayback.com]

Jake, you're throwing forks in my road! :)

One fork is the style path. It's an imposed look and feel. This is appropriate for another site I publish because the users are primarily the same person over and over and over. They're clones of each other. The font gives it a personality that appeals to that demographic and together with it's kick ass content helps differentiate it from competitors. I'm keeping my fonts for that site.

The other path of allowing the user's device choose the font style might be more appropriate because the demographic spans pretty much everyone/ So I think for that site it's workable to let their device do the choosing.

Latest visitor feedback is that the site looks sharper and more focused. So far so good! :)

Latest visitor feedback is that the site looks sharper and more focused. So far so good! :)

An example that even the best of us aren't "font designers" (as in using fonts properly for display purposes) and the old rule: "One font, three sizes, two styles" holds true. The "styles" are italic and bold.

I will suppress my inner pedant and stick with the common if technically incorrect meaning of "font" as it is used that way in so many applications.

I have stuck with using families almost from the beginning in web design but most people think that what they have on their machine is what everybody has. In print publication I get fed up with people sending me PDFs for advertising copy without the fonts embedded. One of these days I really must pay for a copy of Helvetica.

I always used either browser defaults or declared fonts in CSS. However when I developed for mobile responsive, I found it better to install font downloads for presentation control across devices.

For some applications that makes perfect sense. I tend to avoid any extra overhead if possible. If not, then embed the font and go from there.

One problem is that mobile devices have fewer fonts installed, so old fashioned font stacks work less well on them, as keplyr pointed out. On the other hand their default fonts are designed to be readable at small sizes, so falling back to them is not a bad idea.

I have sites that use old fashioned font stacks, and even when I embed fonts I try to use those will small file sizes (it still creates an extra request, of course) and put them on the server.

On the other hand their default fonts are designed to be readable at small sizes, so falling back to them is not a bad idea.

I agree. I believe that the default fonts chosen by Apple and Android manufacturers are the best for those devices. The native fonts are what the users are used to seeing, so there's a practical reason to carry over that sense of familiarity (trust building). I believe that when a person lands on my page and sees the native fonts they are used to seeing (even if they don't consciously notice), they unconsciously give it a higher level of trust.

As one of my site visitors commented, it looked sharper. They didn't know what the change was, but they did assign a positive meaning to it. I have yet to receive a negative feedback for this change.

Interesting to come across this thread, because it is something I have been pondering over for a couple of weeks. I like the idea of reverting to system defaults because they are a known factor. The default fonts have been selected for a reason and not simply picked at random so you can be fairly assured that they work well for the specific device. It involves losing a little bit of design control, but I think it is worth it. Scaling is one area where I have seen some issues. I generally display different font sizes based on screen size and even although I am passing the same values, it is surprising how some fonts give the illusion of being much larger, even although they are in fact the same size.

Again because this is a system default font the user of the device will be used to it, and it will almost certainly fit in well with the UX that he/she is used to.

One thing to take into account is making things look the same no matter what system, OS or browser. Is it right to simply stop doing this with regards to fonts? Personally, I think it is.

Mack.

I have different view on this.

The downside in my view is, as Keyplyr stated above, responsive design. It is difficult enough, managing your layout across multiple screen sizes, if you add to that the possibility of varying font width it becomes nearly impossible to know how your layout will appear on a user's screen.

As for the upside, I think the benefit is negligible, provided you stick to commonly used fonts downloaded from commonly used CDN's (eg: using google fonts open-sans or roboto).
In most cases users will already have come across these fonts when browsing other sites, so the font can be loaded from their cache.

Scaling is one area where I have seen some issues.

I am using percentages for font size. I admit it's debatable as to whether that's the best course to take. Many are successfully using a mix of percentages and em for scalable font sizes.

if you add to that the possibility of varying font width it becomes nearly impossible to know how your layout will appear on a user's screen.

That's a valid concern. I have tested across a range of devices and so far it's looking good but I admit it's possible that it might look bad on someone's device that I haven't yet tested.

Although I haven't done so, one could set the font weight and letter spacing variables via CSS. Out of all the font related styles, for me it's line height that is most important.

I'm working on a WordPress site right now, haven't gone font-less yet, but I've already set the line-height. Once it's all done I'm going to remove the fonts and see how it works!

Many are successfully using a mix of percentages and em for scalable font sizes.

But, but, splutter, but they're the same thing. 1.5em = 150% and so on.

Many are successfully using a mix of percentages and em for scalable font sizes.

More and more people are using rem. The problem with percentages and em is that they are multiplicative, so if you are reusing components you can get odd results.

Jake, you're throwing forks in my road!

How about one more fork. If you want to go crazy with fonts, you're just going to incur a load penalty. But what if you have just one font that you just *have* to have and you do not want it to delay your critical path rendering? Well, you can actually inline it with base64 encoding.

This can lead to *massive* CSS files. I was looking at one the other day that was 30,000 lines (fonts and some small images like icons were all base64 encoded). But, it's a single request and if you're serving your CSS files gzipped, you're getting decent compression (rule of thumb for jpegs is that you add about a third to the size which might be worth it for a 1KB icon, but not for a 1MB hero image). Of course, if you inline it in your HTML, you'll also not be caching it, so your font download happens over and over, but if you base64 encode it in your CSS, it will be cached as long as the CSS is cached.

The problem with percentages and em is that they are multiplicative, so if you are reusing components you can get odd results.

I will agree with that, but only in the context of the coder not paying attention to their own CSS rules. Once set and defined, that should be the end of it.

On browser defaults: Most will do exactly what is desired for responsive, mobile, cross platform. Leave out the over think and, of course, test, test, test!

There is a point of diminishing returns when chasing down the "oddities" with some screens and resolutions. That time might be better spent enjoying a beverage while fishing... or watching tube, listening to audio, etc.

coder not paying attention to their own CSS rules

I think most commonly, it's an issue when you apply fonts on tags rather than classes and then you have a content management system that outputs a nested list. Of course, you can account for this in the CSS (apply to child elements only, require a class, etc).

So yes, fundamentally, it's a problem of poor coding or, perhaps more charitably, unintended consequences of some of your code where the backend team thinks nesting is just fine and the front end team doesn't account for it.

I use the following, no downloaded fonts required:

 font-family: "Helvetica Neue", "Roboto", Helvetica, Arial, sans-serif;

There is a useful online tool subsetter, which helps to trim font-files from unused characters. It might be helpful or interesting for some people in this thread. You can find it at subsetter.com.

About Subsetter: "Web FontFonts are built to serve most people’s needs, and often contain a huge number of glyphs. Yet most of the time you’ll only need a few of them! By dropping what you don’t need, you can greatly reduce the font file size to optimize bandwidth usage, make your websites faster, and reduce high-traffic costs."

I was thinking when I mentioned base64 encoding, that subsetting would be crucial if you go that route. Thanks for the tool recommendation