Type foundry websites can’t follow the recommendations prescribed for all websites. Sometimes, a foundry or type specimen site will need to break “best practices,” or even do the exact opposite.
For example, the site might:
Load many, many, fonts A fairly obvious one. The typical recommendation is to limit the number of fonts a site uses, to improve the page load time and size. A foundry will be loading many fonts, and more as time goes on.
Wait indefinitely for fonts to load There are many font loading strategies for other sites, ex. quickly reverting to fallback fonts if the fonts cannot be loaded for some reason, that aren’t appropriate for foundry sites. With the exception of the user interface font, the fonts are actually the content. So, it makes sense to wait wait for them instead of showing a fallback font, even if we’d otherwise be showing “blank” content.
Namespace font families Websites might use the font’s full name in their CSS, or might make it possible to load a local version of the font if it happens to be present on the person’s system. This can cause problems when a type designers goes to their their own site: if the they have a newer (possibly buggy or in-progress) versions of the font installed on their own computer, it’s very confusing if those fonts appear instead of the uploaded versions everyone else will see.
Opt-out of translations Portions of a foundry site can prevent a browser’s well-intentioned suggestion to auto-translate certain text. In specimen text, the foundry and the visitor will want it to stay in the original language, even if they can’t read it. Depending on the scripts and character coverages in play, the font might not even support the language after the translation.
There are more, but the reason is typically the same: the typeface is the content, and the text isn’t.
Until next time,