Webfont formats for self hosting

Malcolm Wooden

We are starting to offer webfonts from our website for self hosting. Our plan is to supply css based URI data in WOFF and WOFF2 formats (no TTF's, OTF's, SVG's or EOT's).
The advantages are: less data to supply, it's easier to implement for the client, slightly more secure.
Disadvanteges are: no support for older system/browser configurations.

I'm interested to know what others here think of this idea.

James Puckett

What will waste more of your time: converting your fonts to legacy formats or email and phone support for people who insist that they need fonts in legacy formats?

Malcolm Wooden

Thanks for the comment James. This is one of the main considerations for doing what we are doing. It surely is a bit of a gamble but we will be issuing clear guidelines on how to implement the font data in various ways.

We have supplied webfonts in this way to some of our custom work clients and they have been surprised that webfonts can work in this way and at how easy it is to get the fonts to work.

kupfers

There have been several threads on here discussing this topic recently. I recommend you search the forum archive.

Roel Nieskens

Will you offer the WOFF/WOFF2 fonts as base64-ed URI strings in CSS, or also as regular binary files?

PabloImpallari

If you offer base64 encoded css, and you ever update the fonts: all your clients will need to update their css files too.
If you link directly to the font files, when you update the fonts all your clients get the update instantly. Without any action required on their part.

Roel Nieskens

When you're offering fonts for self hosting, the client will need to update anyway, be it font.woff or font.css.

The bigger disadvantage of base64-ed fonts is that they will be downloaded regardless of if they actually being used. If you include four weights, all four will be downloaded, even if you only use one on that specific page. With regular font files, the browser will only fire off a download if the weight is actually being used.

But wait, there's more! https://www.bramstein.com/writing/web-font-anti-patterns-inlining.html

Malcolm Wooden

Roel, thank you for the link, there are some interesting points to consider in that piece.

Richard Fink

Roel Nieskens said:

 But wait, there's more! https://www.bramstein.com/writing/web-font-anti-patterns-inlining.html

I'm a big fan of Bram Stein. But the phrase 'anti-pattern' is just terrible and I wish he wouldn't use it. Whoever coined that term needs a swift smack upside the head.
You might as well say 'poor practice' or 'error prone' or 'troublesome' or something like that and then maybe everybody will know what the hell it is you're attempting to say.
Anti-pattern should be shoved down the same hole as the word 'orthogonal'.
IMHO.
I hate language that obfuscates. 
  

Mark Simonson

Good luck with that. The term has been in use for twenty years now. It's kind of jargony, but it has a more precise meaning than your suggested alternatives.

Richard Fink

Mark Simonson said:

Good luck with that. The term has been in use for twenty years now. It's kind of jargony, but it has a more precise meaning than your suggested alternatives.

Actually, we've all had good luck with stuff like that in recent years. State and federal legislatures have passed laws banning, in governmental communications, the use of jargon and the bloated, pompous, and obfuscatory "official style" of writing  - otherwise known as 'bureaucratese'.  Plain diction and its first cousin, brevity, are in style.

Look, I'm not selling wolf tickets about how language is going to hell these days but at least you agree with me that 'anti-pattern' is jargony. But do you agree that, unlike "selling wolf tickets", the phrase is devoid of any enlightening imagery? When you look up a new term and it leaves you more bored and confused than you were before you looked it up, I say there's a problem.
When I first saw it, I looked up the definition of anti-pattern on Wikipedia and a couple of other places and I still cannot square, in my mind, the ordinary meanings of both 'anti' and 'pattern' with those explanations.

Since you seem familiar with it - without consulting nuthin' and risk skewing the result - could you tell me what it means in your own words?
Maybe I'm just missing it.

(Way, way off-topic, I know. Sorry folks.)

Mark Simonson

It means a common solution to a problem that doesn't really work that well, or actually causes other problems.

Roel Nieskens

I would've called this article "Wonky webfont fuckups", so count your blessings and be glad Bram Stein wrote it.

On topic: having taken a look at DTP's implementation I'm happy to see clean and optimised WOFF and WOFF2 files. But the CSS solution is not ideal. Next to what's already mentioned, in this specific implementation you will download every font, in both WOFF and WOFF2, because they're both in the CSS file. Browsers that support WOFF2 still receive a CSS file that includes a WOFF. You'd usually work around this problem by doing user agent sniffing and offering a CSS file with only the format supported by that browser.

All in all, I'd prefer regular font files because you simply avoid all the issues mentioned. Bram Stein advises to only use it when you're using a lot of fonts on your site, which could probably be classified as an edge case. I'd personally even then rely on regular font files (and hope for HTTP/2 support to increase soon), and only use inlined fonts for extremely small fonts, e.g. sample fonts with a very limited character set.

Malcolm Wooden

Roel, many thanks for your analysis, you make some very valid points.

The point you made in your direct message about not mapping every font to 'normal' is not one we would agree with. In our experience the Regular/Bold relationships that are defined for desktop fonts are not always what a web designer/developer will use. For this reason we set everything to 'normal' so that the developer can set-up the mapping themselves.

Roel Nieskens

That sounds a bit like "some might not want to use our weight mappings, so no-one gets to use weight mappings."  But that means that instead of using the web's natural method to define and use weights through the font-weight property, you completely disable this option for developers. The alternative is then to misuse font families to differentiate between weights. Instead of:

h1 {
  font-family: MyFont;
  font-weight: bold;
}
p {
  font-family: MyFont;
  font-weight: normal;
}

You are forced to do:

h1 {
  font-family: MyFontBold;
  font-weight: normal;
}
p {
  font-family: MyFontNormal;
  font-weight: normal;
}<br>

I would personally count that as a serious strike against using such a service. It doesn't match with best practices and you'd need to refactor your CSS to use families instead of weights. If that's even possible — lots of CMSes, plugins and libraries can't easily be hacked to do so. That may be something to keep in mind.

Richard Fink

Mark Simonson said:

It means a common solution to a problem that doesn't really work that well, or actually causes other problems.

Sorry for my absence - ok, so what's 'anti' or 'pattern' got to do with that?  Without doing much thinking or clicking over to a thesaurus, 'Problematical' or ill-advised would do just as well, I think and that would be descriptive to everybody, no exposure to technical jargon required. 

Other than that - I didn't look at what Roel is writing about but I'll take a look and come back.

Georg Seifert

If you define woff and woff2 in your css, the browser will only download one. It always picks the first it supports.
and the style linking in the fonts itself is ignored. You need to build that relationship in the font-face declaration. 

Simon Cozens

To understand the concept of an antipattern, you have to - sorry to be trite - understand the concept of a pattern. And I think this is worth spelling out because it may well have something interesting to say to the discipline of type design.

The idea of "patterns" in software engineering was developed by (very forced) analogy with the book "A Pattern Language" by Christopher Alexander.

Alexander was an architect who wanted to establish a common language encapsulating common solutions to common problems; a higher level than just describing architectural features, ("an alcove") but describing best practices.

His definition was as follows: "A pattern is a careful description of a perennial solution to a recurring problem within a building context, describing one of the configurations that brings life to a building.

Each pattern describes a problem that occurs over and over again in our environment, and then describes the core solution to that problem, in such a way that you can use the solution a million times over, without ever doing it the same way twice."

In other words, if a designer could recognise they had a particular situation and see that it could be solved by inserting a "bed alcove", the job of architecture could be done much more easily. They still need to do the design work of choosing appropriate solutions and making those solutions form a unified whole, but recognising the need for "a bed alcove" solves the conceptual problem. It also solves the communication problem.

A senior architect can look at a design and go "hey, what you need here is a bed alcove", and the junior can go away and implement it.

I don't know if that applies directly to type design. Something like "reverse contrast" might be an example of a phrase that communicates a way of approaching a particular design issue. I don't know if there are examples of communicating general ways to solve problems. Would knowing that a designer needs a "Garamond leg" here or there help them to fix an issue?

Where the pattern language gets interesting is that as it was applied to software engineering, it became a substitute for careful thought. Faced with any kind of programming challenge, people would flip through their list of patterns and shoehorn in whatever seemed like the closest fit. Although the Factory Pattern is a good way of dealing with a certain category of object instantiation problems, you don't need a Factory for every single damned object you produce. What was intended to demonstrate good ways to solve known problems ended up being a straitjacket for the mind.

Which brings us to the idea of an antipattern. An antipattern describes a commonly used but bad solution, an encapsulation of worst practice: if you find yourself doing X, something has gone wrong somewhere. Rigid application of patterns is an antipattern.

I imagine there are kerning antipatterns. I wonder what other type design patterns and antipatterns there are.

Richard Fink

Georg Seifert said:

If you define woff and woff2 in your css, the browser will only download one. It always picks the first it supports.
and the style linking in the fonts itself is ignored. You need to build that relationship in the font-face declaration. 

This is absolutely true. The first supported format wins and the CSS parser moves on. I only read the post it quickly, but I think Roel might have misspoken. Roel?

[Warning: More off-topic etymological musings...]

Simon Cozens said:

To understand the concept of an antipattern, you have to - sorry to be trite - understand the concept of a pattern.

The idea of "patterns" in software engineering was developed by (very forced) analogy with the book "A Pattern Language" by Christopher Alexander

Thanks for the backstory Simon. Interesting. The fact remains that Christopher Alexander assigned the term "pattern" to something that previously wasn't referred to by that term. I don't know if he's an academic, but academics are forever trying to coin new usages and words and phrases - they must get some kind of extra credit for them or something. But the question is whether the new coinage takes hold in the language and becomes legal tender, so to speak - meaning that there's a common understanding of the word among the general public. 
The word "pattern" describing what you've described ain't listed as common usage in any dictionary I've consulted online.
Having a recurring, underlying "pattern" seems to be a common attribute of the things Alexander is describing but it falls really short of describing the whole category of things he's lumping together under the term "pattern".

Craig Eliason

Simon Cozens said:

I wonder what other type design patterns and antipatterns there are.

Possible patterns:
Like you suggested, genres of type design could be seen this way (an American gothic, a Venetian humanist, etc.).
Or at a tighter scale, types of serifs/terminals (beaked, lachrymal, ball, etc.)

Possible antipatterns:
Designing letters from A to z seeing them only in alphabetic order, and unspaced. (Really, any approach that sees designing letterforms and establishing spacing as distinct steps.)
Forcing Latin-derived shapes onto superficially similar characters in foreign writing systems.

Mark Simonson

Rich, A Pattern Language was a watershed book in the world of architecture. I read it back when it came out in the eighties and it's one of those books that suddenly makes you see things in a more coherent way. Whatever Alexander's reasons for adopting the term pattern, it was embraced by architects, and others as well, because it represented a useful way of thinking about things. Complain all you want, but that ship has sailed.

(Apologies for continuing this possibly off-topic discussion.)

James Hultquist-Todd

Let’s please try to stay on topic here.

Roel Nieskens

Georg Seifert said:

If you define woff and woff2 in your css, the browser will only download one. It always picks the first it supports.
and the style linking in the fonts itself is ignored. You need to build that relationship in the font-face declaration. 

That's how it works when you reference external files, but both the WOFF and WOFF2 files are included in the CSS file itself as base64 strings, so you still download them both.

And the relation can't be set in the @font-face declaration any more, because they've already been mapped to font-weight:normal and font-style:normal. Your only option is to either overwrite that somehow, or misuse font-family -- and both are rather nasty hacks.

Thierry Blancpain

What would happen if we included WOFF2 as base64 strings, and all the other formats through regular @font-face declarations? I take it would always download the WOFF2, and if that didn’t work in the given browser, also whatever next format it can use?

Roel Nieskens

Indeed, browsers that don't support WOFF2 would have downloaded two formats of your font.

The only clean way to use base64 would be to do the user-agent sniffing trick that Google and Typekit do. Determine which browser the user has, and offer a CSS file specifically optimized for that browser. It can be done, if you don't mind the maintenance and want to run such a backend.

Thierry Blancpain

Thanks, good to know!

Malcolm Wooden

Update:
Here is some interesting information with a list of different font loading methods.
https://www.zachleat.com/web/comprehensive-webfonts/#foft