Стандартные и безопасные шрифты CSS
Безопасные шрифты – это набор шрифтов, устанавливаемый вместе с операционной системой (Windows, MacOS, Unix/Linux).
Чтобы сайт в любой операционной системе открывался одинаково, принято в CSS-свойстве font-family задавать несколько названий шрифтов, перечисленных через запятую.
Последним указывается семейство шрифта, он используется, если в системе ни один из перечисленных не найден.
Список безопасных шрифтов:
| ‘Times New Roman’, Times, serif | Съешь же ещё этих мягких французских булок |
| Georgia, serif | Съешь же ещё этих мягких французских булок |
| Arial, Helvetica, sans-serif | Съешь же ещё этих мягких французских булок |
| ‘Arial Black’, Gadget, sans-serif | Съешь же ещё этих мягких французских булок |
| Verdana, Geneva, sans-serif | Съешь же ещё этих мягких французских булок |
| ‘Trebuchet MS’, Helvetica, sans-serif | Съешь же ещё этих мягких французских булок |
| Impact, Charcoal, sans-serif | Съешь же ещё этих мягких французских булок |
| ‘Comic Sans MS’, cursive, sans-serif | Съешь же ещё этих мягких французских булок |
| ‘Courier New’, Courier, monospace | Съешь же ещё этих мягких французских булок |
Далее о каждом шрифте подробнее:
Times New Roman
Where to set font-family: body or html element?
If you are using rem units, make sure to set the base font size on the html element. rem units are based off the font size of the root element, which is the html element.
10 Answers 10
The short answer is, you can use either. Since every displayed element is a descendant of the body element, and the body element itself is the child of the html element, all elements that inherit the font-family property will happily adopt it from either. (If a particular element doesn’t inherit it, you can always override its font-family property with a value of inherit .)
But what is best practice, and why? That’s a bit harder to answer, but I’ll have a go. Let’s start with semantics…
The html element represents the whole document (including non-visible metadata), while the body element represents the content of the document. Since font-family is a property of styled content, it would seem logical to apply it to body . That’s one point for body .
Next question: Where do the browsers define text formatting properties like font-family ? I looked at the user agent stylesheets for Safari (WebKit), Mozilla Firefox and Chrome, and also used the Web Inspector on a page with no overriding CSS, but I couldn’t find a global font-family declaration anywhere. But here’s something interesting… In Safari, the global text color property is defined on the html element. So, if that’s anything to go by, it suggests WebKit browsers do define global font properties on the html element.
There are CSS resets that also tackle it here, like Bootstrap’s _reboot.scss file:
// 2. Change the default font family in all browsers. html < font-family: sans-serif; // 2 … >Still, we can override this on the body element, and that is just what Bootstrap does a few lines later:
The CSS specs (as far as I know) don’t dictate where font-family is declared (it applies to ‘all elements’), but it does give us some hints. The first code example in the W3C document CSS Fonts Module Level 3 is this:
The first declaration on the BODY element sets the font family to «Gill Sans». If that font is not available, the user agent (often referred to as a «browser») will use the sans-serif font family which is one of five generic font families which all users agents know. Child elements of BODY will inherit the value of the font-family property.
You Kinda Can Use Custom Fonts in HTML Emails
And you use them pretty much just like you’d use custom fonts on a website. Jaina Mistry had the scoop on this last year over on the Litmus blog:
- AOL Mail
- Native Android mail app (not Gmail app)
- Apple Mail
- iOS Mail
- Outlook 2000
- Outlook.com app
Aside from using a JavaScript font loader, which definitely won’t work in email (no email client will be executing JavaScript), ultimately it comes down to @font-face in CSS. So let’s do that.
Say we wanted to use Lato in an email, if we can. Go do the normal Google Fonts thing and find the URL for loading Lato. If you just visit that URL, you can see it’s loading Lato over @font-face, and you can totally snag that code:
In your HTML template, you’d put that into a block in the , as well as set the font-family :
Notice there are some fallback fonts set there. Might as well fall back to some Lato-like fonts, if we can.
Here we can see this working in the Litmus Builder:
But just to make sure, we’ll have to blast it to some actual email clients and see what happens:
I think the way to think about it is: some do, some don’t, meh, kind of a cool progressive enhancement to help match your brand.
Psst! Create a DigitalOcean account and get $200 in free credit for cloud-based hosting and services.
Comments
This is something I’ve been thinking about: email design. The designs we’re able to achieve on the web, are transitioning to the email. That would then lead me to believe that all said benefits might come w/ same known challenges. How to you account for #ux w/ email? What about latency? Do FOIT or FOUT come into play? What are the fall back rules w/ email engines? #inSearchOf
I think there is an error there. As written above, it shouldn’t work on Gmail on Android. In fact, the screenshot does not seem to depict lato. Check out the curvature of “r” or the shape of the “y”. That is the default Android system font.
Don’t forget: some older Outlook clients require you specify an alternative font in the @font-face block itself: @font-face <
.
mso-font-alt: Arial;
> Otherwise you will see good ol’ Times New Roman as a fallback font.
There’s also the option of backing up custom fonts with (or relying solely upon) modern system font stack: font-family: -apple-system, BlinkMacSystemFont, «Segoe UI», «Roboto», «Oxygen», «Ubuntu», «Cantarell», «Fira Sans», «Droid Sans», «Helvetica Neue», sans-serif;
A potential “gotcha” to look out for, is that some email service providers incorrectly count the loading of an @font-face font as a click or open. Best to test before using @font-face in your production emails.
a big gotcha to watch out for when doing these emails: if you’re not the designer of the email, and the designer will see the email once it’s sent, inform them about the fact a fallback font will get used if the email client doesn’t support custom fonts. You should also seriously avoid doing anything fancy with typography, don’t try overlapping text in some cool way, because once that fallback font kicks in your beautiful typographic work of art will look like garbage. percieved line-heights can change, spacing of letters can change, nearly everything about the font can be a bit off when it fallsback. Keep It Simple Stupid. Fortunately some of this you might be able to work around by using @supports in your CSS. a lot of email clients don’t support @Supports yet but if you’re familiar with @supports you know that lack of support for @supports just means you specify a fallback before the @supports.
Thanks for the shout-out Chris! Though I believe the screenshot for Gmail on Android shows a negative outcome—the web font Lato is not displayed. Still holding out for Gmail to enable web fonts on their apps.
One thing to note is Outlook’s greater than 2007 will revert to Times New Roman as it will not read the font stack properly. The best bet will be to put an important tag to the body tag that has web fonts and declare the fonts inline for each element. Or with the important tag in the body you can use a Outlook conditional statement for the fonts in the body.