Webfont formats

Wei Huang

As of today what's still necessary? I found an answer here regarding eot, ttf and svg but I didn't understand the answer for ttf though, regarding it being "scrutinised more"?

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

Up util now, I've used Paul Irish's bulletproof font-face sytax

But I was just looking at support for .woff and .woff2 files on caniuse and it says woff is supported in IE9+. Most articles on this topic are from around 2009, which at the time of this writing was a full 7 years ago. Do we really need to keep declaring ttf, otf, eot, and svg when woff now enjoys such wide support?

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 were abandoned 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.

Also note that 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).

As for TTF/OTF, don't use them online. Even though WOFF is just a thin wrapper around a TTF/OTF file (with optional compression), yielding a byte-for-byte identical file when the WOFF is decoded, TTF/OTF are universal (OpenType-supporting system) fonts, and so are scrutenized more, especially by versions of IE. Using WOFF, which as a filetype makes it explicit this is a web (open) font (format), a "laxed" form of scrutiny means that some fonts that would fail a TTF/OTF verification check 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)

In conlusion: hurray for the march of progress, just use WOFF.

attar

{woff2, woff} with ttf inside I guess.

Yªssin Bªggªr

We often get requests for TTFs because of older versions of the Android browser. Android is bad at updates (and I can confirm that personnaly, an older phone couldn't upgrade to a newer version at all after less than 1 year).
Likewise, I'm not sure older Windows/IE users can be dismissed that quickly, therefore we also still deliver EOT. I guess it depends on your clients and how thorough they want to be with their support.
I would certainly prefere to deliver WOFF/WOFF2 only but it seems a bit radical at the moment. I'm curious how other foundries deal with this…

Thomas Phinney

WOFF-only seems increasingly reasonable. Opera Mini doesn't support it, but it doesn't support anything, so no loss there!

[Deleted User]

The user and all related content has been deleted.

Jack Jennings

For those going WOFF-only do you supply the legacy formats on request and/or do you ever actually receive such a request?

John Hudson

Anyone offering WOFF2 yet?

Mads Wildgaard

We supply WOFF&2 only.
Sometimes EOT and TTFs are requested, and I guess it's just easy then, to have the actual files floating about — rather than spending your day double checking and re-exporting.
It all boils down to the audience targeted, by the customer/client, as yassin points out.

Mark Record

I prefer to keep one foot behind in terms of supported formats. 
We only recently ditched ttf/svg and are currently delivering eot/woff/woff2.
Large/global corporations still receive the whole kit (eot/woff/woff2/ttf/svg) since they're usually supporting grandmothers using WinXP on CRT monitors and old, never-going-to-be-updated Android phones. 
We get occasional requests for ttf/svg. Most of those requests are from customers who are unaware that they don't need those formats anymore. 

Roel Nieskens

You'll have to optimise for when custom fonts don't load anyway (bad connectivity, content blockers, mobile browsers without support), so why not offer older browsers this fallback as well? Sticking to WOFF is a great way to "cut the mustard", offering a well compressed font format to modern browsers, and solid font stack for the remaining few old browsers.

@Wei Huang: I think Mike Kamerman's comment about OTF/TTF being scrutinising more perhaps is about OTF/TTF having to be valid for desktop use (installed on your local OS), whereas WOFF only needs to work in a browser.

Richard Fink

This forum caters to people who make fonts, not web designers. And I'm sensing from some of the replies that the initial question is getting skewed a bit.

The question asked at the beginning of this thread - quoted from a Quora.com posting - is about best practice regarding which font formats to include in the style sheet of a web page using @font-face, and not "what web font formats do you supply to your clients and/or customers".
Two very different questions, those.


Some considerations:
As a creator of web pages, I know that, today, Windows XP is still used by around 7% of PC users. That's a lot of people.  Now, some might be using Chrome or Firefox and so feeding them a Woff file is no problem. But some are undoubtedly using IE8 and unless there's an EOT, they won't see the font.

Also, there's the question of matching the file formats named in the @font-face declaration with the files themselves. 
Style Sheets are usually site-wide things with the same .css file being called by all the pages on the site. 
And code like that tends to be self-perpetuating. You'd be surprised at how many web designers/developers will, by rote, copy the same declaration the site's been using, just change file names, and either not know that a Woff file is all there is or just overlook the change. I would recommend continuing to supply an EOT, a Woff, and a TTF - munged or not munged to control whether it will install as a "desktop" font.
Why rock the boat?  

I would also add a WOFF2 file to the mix, but I'll get to that in a second. 

If the @font-face stack calls for an EOT and the browser supports EOT (only IE does), then the browser will attempt to call the file from the server. If the file isn't there, the browser is going to spin its wheels a little until timing out and moving on to the next file specified in the declaration which will probably be a Woff, so at that point, as long as the browser supports Woff, the search will be over, the Woff will download, and the browser will look no further in the @font-face declaration.
So, essentially we're talking about accommodating IE8 or not. Since I think it's good idea to not rock the boat and give the customer what the customer is used to getting, my vote is to supply an EOT and leave the existing CSS structure intact and thus support IE8 for a bit longer. Feels like win/win to me.
  
Now, for forward-looking optimization, there is no reason on earth not to start including a call to a Woff2 file, as long as one exists, of course.  Much better compression. 
MSFT just announced that Edge will have Woff2 support by summer and Firefox and Chrome already do.
Support for Woff2 is certain to become standard so why not get ahead of the game and let users get the benefit ASAP?


Note that the CSS declaration should call for the WOFF2 immediately before the call for the WOFF file. 
Like this example:
@font-face {

font-family: 'testfont';

src: url('test-a-EOT.eot');

src: url('test-a-EOT.eot?#iefix') format('embedded-opentype'),url('test-a-WOFF2.woff2') format('woff2'),url('test-a-WOFF.woff') format('woff'),url('test-a-TTF.ttf') format('truetype');

font-weight: normal;font-style: normal;
}

In this way, those browsers that support Woff2 will download and end the search at that point - with the most optimized format offered before the others.

Just my take on the whole thing. 

Jack Jennings

Richard—according to caniuse, IE8 users in the US make up ~1% of internet traffic (and less globally): http://caniuse.com/#search=woff

I may be so bold as to say the question would be better phrased as "what formats are still practical", given than any additional format is another potential point of failure—both for the web developer and for the type designer. Clearly it's a judgement call, but given that few developers I know still test in IE8 (let alone the next few successive versions), at some point you're providing a file that's not going to even be verified to be functional.

SiDaniels

I didn't read the entire thread, so sorry if this was mentioned, but the TTF/OTF "scrutiny" might be related to IE only working with raw fonts set to "installable embedding".  

Richard Fink

First of all, a part of the answer given to the Quora.com question is wrong:

Also note that 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. 

This phrase from above, is incorrect:

>meaning that IE9 is no longer supported for Windows XP

IE9 was never installable in Windows XP. The IE versions possible to install on XP capped out at IE 8.0. For a web font to show up in IE on XP, it must be in EOT format.
Just wanted to set the record straight on that.

Next,

Jack Jennings said:

Richard—according to caniuse, IE8 users in the US make up ~1% of internet traffic (and less globally): http://caniuse.com/#search=woff

.77%  is the precise number according to the link you provided. Which, BTW, doesn't agree with some of the other browser stat sites listed  as major sources on:
https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

For example, https://www.netmarketshare.com/ says this:




And since that 7.52% does roughly agree with the current XP usage stats, there's a bit of extra credence due here.

Maybe....

The two other sources mentioned in wikipedia's roundup, puts IE8 usage at the same level, roughly, that caniuse.com does.  Depending upon the country you filter the data for, it hovers slightly above or slightly below 1%.

Who's numbers reflect reality the best?
I don't know.

However, on the US Government stat site, which monitors all browser requests to all government websites - like the US Postal Service, the IRS, the US Weather Service, etc... - the number in the last 90 days is .6% of visits numbering roughly 1.29 Billion visits. (That's the total number of visits (2.12 Billion) adjusted by the percentage of browsers running on Desktop operating systems.) 
Now, .6% sounds rather low, right? Well, in the number of users, it's not. Just for the US Government web sites, it adds up to almost 8 million visits. Now, I have no idea what percentage of all web traffic is generated by those government web sites, but it's fair to say that, at best, it's a modest percentage.  Which makes the number of actual IE8 users balloon to tens of millions of users at least.

If you don't see any harm in cutting off web fonts to that many users, then you don't.

I do. 

Also, there's another problem worth mentioning.
The IE Edge browser does not support EOT.
However, Internet Explorer, sits right alongside Edge in Windows 10 with each represented by a blue "e". Most users probably don't even know which one they are using at any given time. Yet IE does support EOT and I do not know if it will ever support Woff2 as Edge will.  (Anybody know? Si?)

To sum up: first, do no harm. And cutting EOT out of the picture, at this date, can do harm with no benefit at all to justify the harm.
Many font suppliers have been offering EOT's and Woffs and some kind of TTF for years now.  Not a problem. And so all of it is "practical", which you say is your main criteria. Adding Woff2 will only be extra work if the conversion processes aren't automated but I suspect most houses have that part down to a science by now. 

Thanks, for making me take a closer look at this, Jack. 

Richard Fink

Oh, and as far as testing the EOT, I can't see how anything has changed. IE on Windows 10 will verify if the EOT works.  I also checked IE Tab - the Chrome extension that gives you a tab within Chrome running the IE engine - and it, too, loads an EOT so that's two convenient ways to test right there.

Ofir Shavit

Obviously not a representative sample of global population (I guess most our website visitors are designers) but I have checked the stats of browsers used by Fontark visitors in the past 30 days...

IE 8 is only 0.083% of the total traffic and only 2.6% of IE visitors (IE 11 takes 86%).

All IE users are only 3.2% of our total visitors, not including Edge (1%).

Roel Nieskens

If only 0.6% of users can't handle WOFF because they use IE8 or before, a good option is to serve them the fallback font stack. This should still give them a proper user experience — the same you give to the 300 million Opera Mini users, the ones on slow networks and the ones who disabled fonts with content blockers.

Yªssin Bªggªr

Like Richard Fink, I find the reference to percentages problematic. Depending on clients, 1% or 0.5% can still represent 10-100 thousands of people. Brands investing a good amount of money in fonts don't really want to hear about fallback.

Deleted Account

I agree. We pay no attention to market shares. We keep the web font format carousel running all the time for new formats to jump on and old ones to jump off. It's hard to stop serving a format until it's dead, deceased, given up the ghost, in the ground, six feet under, and independently certified to be pushing up daisies. 

Intellifont, and Speedo qualify among the "standards". 

Web font Formats are, as simple wrappers on a few different contour formats — free. The question of what is the right thing in the wrapper, is automated in most good services, to not only work in the browser environments required, but work as well as possible in each, given most commercial and non-profit web site requirements.

So, with ttf, svg, OTF, and probably a stroke font format, (aka the sheep), all to be wrapped in woff clothing, it's now up to the independent web developer to figure out which sheep in there is the "best fit". This is going to get more complex, for sure, as variations, color, size masters and additions to glyph repertoires become more common in use. 

Richard Fink

@David Berlow said:

"I agree". 

With what, exactly? What practices do you follow at Font Bureau and Webtype?

Less important: 
What's Intellifont and Speedo?
And Monty Python's 'Dead Parrot Sketch' occasionally comes in handy, doesn't it?

Pls clarify.

Thanks.

Richard Fink

@Ofir Shavit , @Roel Nieskens , @ybaggar :

Setting David Berlow's post and my response to it aside, nothing I saw in the last few posts before David's makes a compelling argument for not providing EOT or woff2.
  

I've been working up a bio page for myself on Github - and the number of users viewing it with IE8 will probably be zero but still I included EOT. Right now, not every browser supports woff2 but still I included woff2. Why not?

It costs me nothing but a few extra clicks of my mouse to accommodate every user agent capable of receiving web fonts with maximum efficiency.
Why would I stop short of that? 

Also, just a quick word about browser stats: I haven't checked browser stats in a long time - this thread took me back there - and I was glad to see that there are a few choices with more breadth than there used to be - especially that US Government Site.

Browser stats have to be viewed with great skepticism no matter what the source. Some years ago a lot of web developers would quote the stats from W3Schools not knowing - or not caring - that the visitors to W3Schools were way more likely to be using the latest Firefox or Chrome browser than average web users. Those stats were useless as a guide.
As are the stats from a site like Fontark.com.

When can EOT start to be treated as obsolete? Well, Mike Kamermans' answer to the question on Quora might give a clue:

"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."

7% usage of XP today means that many millions of users have IE8 at their fingertips. I wouldn't even bother to re-evaluate the policy of including EOT until 2020. If XP usage is down to next to nothing by then, I think I'd start to feel comfortable leaving EOT out of any new implementations.

And that's all I have to say about that.

Ofir Shavit

I respect all considerations. If a client/someone want EOT, it's fine with me.

Personally I really don't like my css to be messy, and I think it is the browser's providers responsibility to make their product flexible/adaptive to the few standards out there and not the millions of website builders that have to juggle with each browser limitations, but reality is opposite, it reminds me that we live in middle ages (it's always middle ages). I also think that outdated browsers users of choice don't mind that much about their surfing experience, and those forced, understand the flaws.

I have gladly waved svg from my webfonts pack, same goes to eot and as far as I'm concerned, the more (out of it) the better

Roel Nieskens

Yes, browser stats schmrowser stats. If you're running www.ie8fanclub.com you'll have different stats than www.supermodernwebstuff.com.

It costs me nothing but a few extra clicks of my mouse to accommodate every user agent capable of receiving web fonts with maximum efficiency.
Why would I stop short of that? 

I'm probably preaching to the wrong audience here, but the answer to that is "because accessibly content is more important than webfonts". Leaving out TTF roughy translates to "not serving fonts to older Android devices," for instance. The users on these low-powered devices on (slow) mobile networks will have a lot better experience if they don't have to experience FOUT/FOIT while downloading a couple of 100 kB of TTF. Instead of waiting half a minute before the fonts are downloaded and applied, they get to read your content immediately.

Forward looking enhancements, like WOFF2, is an effort that would benefit a lot more people, now and in the future. Whatever your stance on legacy font formats, this is something you should do.

Richard Fink

I feel like Al Pacino in Godfather III - I try to get away, but I keep getting pulled back into this thread.

Listen to veteran David Berlow - he's been at the cutting edge of digital fonts for a long time. His company runs a web font service. If he doesn't know a thing or two about stuff like this, I don't know who does: 

David Berlow said:

It's hard to stop serving a format until it's dead, deceased, given up the ghost, in the ground, six feet under, and independently certified to be pushing up daisies. 

@Ofir Shavit:

I have gladly waved svg from my webfonts pack, same goes to eot and as far as I'm concerned, the more (out of it) the better

I agree with you. It was clear from the outset that SVG was impractical because of bandwidth considerations - I don't think I ever advised anybody to include SVG. If memory serves, the only browser that supported it in any way was Opera, back when they were still working with their own proprietary Presto engine, at least. 
And I agree also that the less CSS there is, the better. There will come a time to forget about EOT. Good riddance! Now just isn't the time. IMHO. 

@Roel Nieskens:

Yes, browser stats schmrowser stats. If you're running www.ie8fanclub.com you'll have different stats than www.supermodernwebstuff.com.

I like how you used domain names to make the point. Color me jealous.

I'm confused about the rest:

It costs me nothing but a few extra clicks of my mouse to accommodate every user agent capable of receiving web fonts with maximum efficiency.
Why would I stop short of that? 

I'm probably preaching to the wrong audience here, but the answer to that is "because accessibly content is more important than webfonts". Leaving out TTF roughy translates to "not serving fonts to older Android devices," for instance. The users on these low-powered devices on (slow) mobile networks will have a lot better experience if they don't have to experience FOUT/FOIT while downloading a couple of 100 kB of TTF. Instead of waiting half a minute before the fonts are downloaded and applied, they get to read your content immediately.

Forward looking enhancements, like WOFF2, is an effort that would benefit a lot more people, now and in the future. Whatever your stance on legacy font formats, this is something you should do.

Are you saying that a ttf should NOT be included in the @font-face stack? Or what?
Keeping users in the dark while waiting for a font to download is definitely a serious problem if it's happening. But aren't these users getting the textual content displayed with a locally installed font until the fonts download?
In other words, what, exactly is the problem and what are you suggesting be done about it?

- rich

Roel Nieskens

Most browsers support either EOT (old IE) or WOFF (all other modern browsers), so OTF/TTF would typically be used to target Android devices before version 4.4. Looking at global browser stats, that's twice as many users than IE8 has.

The browsers on these old, underpowered Android phones, will keep the text on a page invisible until the webfont has loaded. So if you're on 3G or worse (GPRS, a wonky public WiFi network), and you visit a website, the actual content — the text you want to read — will be downloaded in a couple of seconds. But then it'll request additional assets: CSS, images, JavaScript, webfonts, etc. While the webfont trickles in, the text is kept invisible. This might very well take 30 seconds. Or 60, when you're on a busy network. Or 120, when you're in a train and your phone needs to connect to a new transmission tower every kilometer. If the connection times out, you're out of luck and the text will be kept invisible until the end of time. Hardly ideal.

So, with that in mind, I say: yes, OTF/TTF should not be included in the @font-face stack. Offer Android users your solid fallback font stack, which you'd have to do for the Opera Mini users anyway — a browser that deliberately disables webfonts and has a gobal use base six times as large as IE8. 

Richard Fink

Roel Nieskens said:

Most browsers support either EOT (old IE) or WOFF (all other modern browsers), so OTF/TTF would typically be used to target Android devices before version 4.4. Looking at global browser stats, that's twice as many users than IE8 has.

The browsers on these old, underpowered Android phones, will keep the text on a page invisible until the webfont has loaded. So if you're on 3G or worse (GPRS, a wonky public WiFi network), and you visit a website, the actual content — the text you want to read — will be downloaded in a couple of seconds. But then it'll request additional assets: CSS, images, JavaScript, webfonts, etc. While the webfont trickles in, the text is kept invisible. This might very well take 30 seconds. Or 60, when you're on a busy network. Or 120, when you're in a train and your phone needs to connect to a new transmission tower every kilometer. If the connection times out, you're out of luck and the text will be kept invisible until the end of time. Hardly ideal.

So, with that in mind, I say: yes, OTF/TTF should not be included in the @font-face stack. Offer Android users your solid fallback font stack, which you'd have to do for the Opera Mini users anyway — a browser that deliberately disables webfonts and has a gobal use base six times as large as IE8. 

Thank you, Roel. That clarifies it for me.
I'm so used to seeing a ttf at the end of the @font-face list, my mind is trying to wrap itself around what you are proposing. 
You might be right. This might make sense. At this stage of the game, what's the point of listing a ttf or otf? (Except in test pages which I write a lot of.) Hmmm.......

However, I do have a couple of immediate reactions:

Wouldn't using a Font Loading API of some sort - in the case of the old Android devices it would probably need to be a polyfill of some sort - wouldn't that solve the "invisible to the end of time" problem?
Further, I want to point out that those Android devices won't exist until the end of time, either. It's a problem that time, in the form of product obsolescence, will make disappear eventually.  This is just an observation.
Third, as a best practice, there should always be an OS supplied font fallback specified for user agents that don't - through user settings or by design - don't support web fonts. This is an important thing to remember, that a lot of designers forget. Support is not a given even if all the MAJOR browsers support a standard.

Here, read this by web designer Adam Morse who takes a totally contrarian view and says web fonts are still too ridden with problems to use and web designers should keep to system fonts.  (I don't agree, but I love his 'in your face' arguments!)
http://mrmrs.io/writing/2016/03/17/webfonts/
And here's a rebuttal to Morse's post by Robin Rendle:
https://robinrendle.com/notes/in-defense-of-webfonts/

Now that I've thought about it a little, I think you're right about ttf/otf being optional at this point. I'm trying to come up with a solid reason to include them, and can't so far.

- rich

Roel Nieskens

Yes, default browser behaviour for @font-face is pretty bad, so a font loading strategy is very advisable. Bram Stein has a great write-up about that: https://www.bramstein.com/writing/web-font-loading-patterns.html

Richard Fink

Also worth a bookmark:
http://www.zachleat.com/web/critical-webfonts/
And - for the record: Chrome and FF both support the W3C Font Loading API now.
As of December 2015, it's been implemented by Typekit.