Are Eot, Ttf, and Svg Still Necessary in the Font-Face Declaration

Are eot, ttf, and svg still necessary in the font-face declaration?

October 2018 edit

tl;dr: use WOFF2, every modern browser supports it, with WOFF fallback because IE11 just won't bloody die (update: it finally got an EOL date of June 15, 2022), and without the local() source indicator, because you want everyone to use the same font, not "a different version or even completely different font that happens to use the same name".

The end.

Original 2016 answer

Short answer: no.

EOT is only relevant for IE8 and below (although as trivia: all the way down to IE4. IE actually pioneered webfonts), and SVG fonts as technology (not to be confused with OpenType fonts with SVG outlines) were abandoned (in early 2015) because the limitations were insane once real webfonts started to become available. As of 2016 you just need WOFF. And WOFF2 if you want to take advantage of the newer better version of WOFF that only just became a w3 recommendation (at the time of this answer).

To make things easier, as of January 12th 2016, Microsoft ceased support for IE8 and below, with limited support for IE9: they will now only support the latest available browser for each still supported OS, meaning that IE9 is no longer supported for Windows XP, because XP is itself no longer supported, but is technically still—begrudingly—supported until Vista SP2 and Server 2008 R2 reach the end of extended support in 2017 and 2020, respectively. Of course, for Windows Server 2008 webfont support is irrelevant, and most businesses that still use an old version of Windows skipped Vista, being either on Windows XP (at their own peril) or Windows 7 (which we can pretty much expect to all become Windows 10 in July of 2016, the 29th of which is the last date people can upgrade from 7/8.1—but not 8—to 10 for free).

(April 2017 edit: Windows Vista SP2 went out of support this month, and as such IE9 is now officially no longer supported)

As for TTF/OTF, you don't want to use these online any more than you would want to use TIFF images rather than JPG or PNG: even though WOFF is "just" a thin wrapper around a TTF/OTF data, WOFF/WOFF2 allow the data to be compressed, whereas plain OpenType does not.

Furthermore, TTF/OTF are universal (for systems that support OpenType) fonts, and so are scrutinized more for correctness, especially by versions of IE. Using WOFF, which as a filetype makes it explicit this is a Web (Open) Font (Format), a less strict form of scrutiny means that some fonts that would fail a system OpenType verification pass may still work just fine as webfonts (due to the fact that not all required-for-universality OpenType data is necessary for a font to work in just a web context).

Finally, you get a choice in WOFF formats: Format 1, just called WOFF, is the older format and uses compression based on deflate, similar to PNG compression; and Format 2, called WOFF2, is the newer format with compression based on the brotli algorithm, and also allows for "chopping up" a font into separate files for optimized delivery when dealing with unicode fonts that support multiple languages. You don't need all the files at the same time, so only deliver those files that cover the unicode ranges necessary for a specific page and you keep page size and load times down that little bit more.

In conlusion: hurray for the march of progress, just use WOFF (or WOFF2).

And, of course, remember to indicate the format of your @font-face sources using the format() value.

Why should we include ttf, eot, woff, svg,... in a font-face

Answer in 2019:

Only use WOFF2, or if you need legacy support, WOFF. Do not use any other format

(svg and eot are dead formats, ttf and otf are full system fonts, and should not be used for web purposes)

Original answer from 2012:

In short, font-face is very old, but only recently has been supported by more than IE.

• eot is needed for Internet Explorers that are older than IE9 - they invented the spec, but eot was a proprietary solution.

• ttf and otf are normal old fonts, so some people got annoyed that this meant anyone could download expensive-to-license fonts for free.

• Time passes, SVG 1.1 adds a "fonts" chapter that explains how to model a font purely using SVG markup, and people start to use it. More time passes and it turns out that they are absolutely terrible compared to just a normal font format, and SVG 2 wisely removes the entire chapter again.

• Then, woff gets invented by people with quite a bit of domain knowledge, which makes it possible to host fonts in a way that throws away bits that are critically important for system installation, but irrelevant for the web (making people worried about piracy happy) and allows for internal compression to better suit the needs of the web (making users and hosts happy). This becomes the preferred format.

• 2019 edit A few years later, woff2 gets drafted and accepted, which improves the compression, leading to even smaller files, along with the ability to load a single font "in parts" so that a font that supports 20 scripts can be stored as "chunks" on disk instead, with browsers automatically able to load the font "in parts" as needed, rather than needing to transfer the entire font up front, further improving the typesetting experience.

If you don't want to support IE 8 and lower, and iOS 4 and lower, and android 4.3 or earlier, then you can just use WOFF (and WOFF2, a more highly compressed WOFF, for the newest browsers that support it.)

@font-face {
  font-family: 'MyWebFont';
  src:  url('myfont.woff2') format('woff2'),
        url('myfont.woff') format('woff');
}

Support for woff can be checked at http://caniuse.com/woff

Support for woff2 can be checked at http://caniuse.com/woff2

Any advantage to using SVG font in @font-face instead of TTF/EOT?

It seems to be the only way to use web fonts on Mobile Safari. So that's a pretty big advantage if you're developing for iPhones and iPads. Font Squirrel's @font-face generator can create the appropriate SVG file and CSS syntax from any OpenType font.

Embedding web font, do I need to include all of these: ttf, eot, woff and svg?

It doesn't hurt, TTF, SVG are widely used, EOT is not supported at all. The browser should only load one font file not all four so it doesn't hurt to have then declared for support sake.

http://caniuse.com/#feat=ttf

http://caniuse.com/#feat=woff

http://caniuse.com/#feat=svg

http://caniuse.com/#feat=eot

What is the exact syntax for using svg font files in @font-face rules

To find what to put after the # you'd need to open the SVG file in a text editor and find the <font id="someIdentifier".

For example, Fontello generated SVG files have the following line:

<font id="fontello" horiz-adv-x="1000">

Which makes the @font-face declaration:

@font-face {
  font-family: 'fontello';
  src: url('../font/fontello.eot');
  src: url('../font/fontello.eot?#iefix') format('embedded-opentype'),
       url('../font/fontello.woff2') format('woff2'),
       url('../font/fontello.woff') format('woff'),
       url('../font/fontello.ttf') format('truetype'),
       url('../font/fontello.svg#fontello') format('svg');
  font-weight: normal;
  font-style: normal;
}

The #fontello matches the id attribute in that line within the SVG file. You want to match whatever the id is within your SVG file.

If your id property within the svg file is id="foobar", yours would look like this:

@font-face {
  font-family: "Brandon";
  src: asset_url("#{$font-reg}.eot");
  src:
    asset_url("#{$font-reg}.eot?#iefix") format("embedded-opentype"),
    asset_url("#{$font-reg}.woff2") format("woff2"),
    asset_url("#{$font-reg}.woff") format("woff"),
    asset_url("#{$font-reg}.ttf") format("truetype"),
    asset_url("#{$font-reg}.svg#foobar") format("svg");
  font-weight: 400;
  font-style: normal;
}

Here is official W3C CSS Fonts Module Level 3 documentation referencing the id property. If you forgot to add the identifier then it would simply reference the first defined font.

In the case of SVG fonts, the URL points to an element within a
document containing SVG font definitions. If the element reference is
omitted, a reference to the first defined font is implied. Similarly,
font container formats that can contain more than one font must load
one and only one of the fonts for a given @font-face rule. Fragment
identifiers are used to indicate which font to load. If a container
format lacks a defined fragment identifier scheme, implementations
should use a simple 1-based indexing scheme (e.g. "font-collection#1"
for the first font, "font-collection#2" for the second font).

Hopefully that helps!

Why is the format declared twice in font-face using 'format('extension_here')'

The format(...) part is, by definition, the part that declares the font format. Whatever the url(...) part contains is just a URL, a string used to access a resource. In practice browsers may, in the absence of properly declared information, try to guess the content type of a resource from the last few characters of the URL used to access it, but this is not a good excuse for not writing proper declarations.

The definition of the src descriptor says:

External references consist of a URL, followed by an optional hint
describing the format of the font resource referenced by that URL. The
format hint contains a comma-separated list of format strings that
denote well-known font formats. Conformant user agents must skip
downloading a font resource if the format hints indicate only
unsupported or unknown font formats. If no format hints are supplied,
the user agent should download the font resource.

So if you omit the format(...) part, browsers will download the font resource—they are not expected to analyze the URL before doing that. This may mean considerable inefficiency, since browsers will download resources they cannot handle; only after downloading, say, an EOT font resource will they look at its content and see they cannot handle it and must download the next resource in the list.

What font format should I use for my site

Understanding Font File Types

• WOFF / WOFF2

WOFF fonts often load faster than other formats because they use a compressed version of the structure used by OpenType (OTF) and TrueType (TTF) fonts.

• SVG / SVGZ

ideal for mobile use

• EOT

supported only by IE

• OTF / TTF

The WOFF format was initially created as a reaction to OTF and TTF, in part, because these formats could easily (and illegally) be copied

• ON THE OTHER SIDE:

Google Fonts offers this as a way to use their fonts.

• SOME PERFORMANCE TIPS

Watch the file size

Fonts can be surprisingly heavy, so lean towards options that offer lighter versions. For example, favor a font set that is 50KB versus one that weighs 400KB.
Limit the character set, if possible

Do you really need the bold and black weights for one font? Limiting your font sets to load only what is used is a good idea and there are some good tips on that here.
Consider system fonts for small screens

Many devices are stuck on crappy connections. One trick might be to target larger screens when loading the custom font using @media.

In this example, screens smaller than 1000px will be served a system font instead and screens that wide and above will be served the custom font.

• CONCLUSION:
  Use OTF/TTF(all browsers) & EOT(I.E) for Desktop screens and use system fonts for small screens as they render faster.
  And do consider google fonts. Best choice so far.

---

Related Topics