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.
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.
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.
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
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'.
I hate language that obfuscates.
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.)
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.
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.
You are forced to do:
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.
Other than that - I didn't look at what Roel is writing about but I'll take a look and come back.
and the style linking in the fonts itself is ignored. You need to build that relationship in the font-face declaration.
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.
[Warning: More off-topic etymological musings...]
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".
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.)
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.
(Apologies for continuing this possibly off-topic discussion.)
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.
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.
Here is some interesting information with a list of different font loading methods.