Webfonts: Consider renaming "webfont" to "web font" or "font"

[hellofromtonya]

Part of #41479.

Problem Statement

The termswebfonts and webfont are misaligned to terminology of well-known authoritative standards.

As suggested by @desrosj, this proposal is to consider renaming web font terminology from "webfont" to "web font". In addition, I've expanded this proposal to consider dropping the word "web" and renaming to "font".

Why rename?

The renaming is to align the feature to well-known authoritative standards for consistency and maintainability.

As @desrosj noted, "I know this is a nit, but I think it's important to get it right and be consistent."

As shown below, industry standard refers to a font as "web font" when its font file is served from a web server to the browser. Though technically the API itself is for fonts, meaning web fonts and/or locally installed fonts via local().

Current Choices

• Don't rename to keep "webfont"
• Rename to adopt "web font" instead of "webfont"
• Rename to adopt "font" instead of "webfont"

Proposal 1: Rename to Web Font

Fonts hosted on a web server are primarily called "web fonts".

• MDN refers to them as "web fonts"

Web fonts
... CSS allows you to specify font files, available on the web, to be downloaded along with your website as it's accessed. This means that any browser supporting this CSS feature can display the fonts you've specifically chosen. Amazing!

• From Google Fonts glossary:

A web font is any font used in a website’s design that isn’t installed by default on the end user’s device—a counterpart to a system font.

• The name of the original working group for web fonts
• Caniuse calls it @font-face Web fonts
• Google Fonts FAQ page says "web fonts"
• Google
• Adobe calls Typekit "Typekit Web Fonts" (see the footer link)
• Microsoft's docs refer to them as "web font"

This rename would result in the following class and function name changes:

Current name	New name
WP_Webfonts`	WP_Web_Fonts
WP_Webfonts_Provider_Local	WP_Web_Fonts_Provider_Local
WP_Webfonts_Provider	WP_Web_Fonts_Provider
wp_webfonts()	wp_web_fonts()
wp_register_webfonts()	wp_register_web_fonts()
wp_register_webfont()	wp_register_web_font()
wp_enqueue_webfonts()	wp_enqueue_web_fonts()
wp_enqueue_webfont()	wp_enqueue_web_font()
wp_register_webfont_provider()	wp_register_web_font_provider()
wp_get_webfont_providers()	wp_get_web_font_providers()

as well as all references within code comments.

Proposal 2: Rename to Font

The API itself supports the vision of a font library and management. One part of its functionality is to dynamically generate the @font-face ruleset.

What is @font-face? Per MDN web docs:

The @font-face CSS at-rule specifies a custom font with which to display text; the font can be loaded from either a remote server or a locally-installed font on the user's own computer.

If "web font" means a font file obtained from a web server, then the API's generation of @font-face deals with both web and locally installed fonts (on the user's computer or mobile device).

To be technically accurate, the API then is not limited to only web fonts (font files downloaded to the browser from a web server). Rather it supports "fonts" and the bigger vision of a font library and font management.

This rename would result in the following class and function name changes:

Current name	New name
WP_Webfonts	WP_Fonts
WP_Webfonts_Provider_Local	WP_Fonts_Provider_Local
WP_Webfonts_Provider	WP_Fonts_Provider
wp_webfonts()	wp_fonts()
wp_register_webfonts()	wp_register_fonts()
wp_register_webfont()	wp_register_font()
wp_enqueue_webfonts()	wp_enqueue_fonts()
wp_enqueue_webfont()	wp_enqueue_font()
wp_register_webfont_provider()	wp_register_font_provider()
wp_get_webfont_providers()	wp_get_font_providers()

as well as all references within code comments.

[jonoalderson]

This seems sensible + clearer.

[hellofromtonya]

@jonoalderson any preference of which name to adopt? "web font" or "font"?

[jonoalderson]

Font!

[aristath]

+1 for Font. It's simpler and makes sense

[desrosj]

Thanks for creating a new issue for this!

If "web font" means a font file obtained from a web server, then the API's generation of @font-face deals with both web and locally installed fonts (on the user's computer or mobile device).

To be technically accurate, the API then is not limited to only web fonts (font files downloaded to the browser from a web server). Rather it supports "fonts" and the bigger vision of a font library and font management.

I disagree with these points above. While it is possible that a font may be installed on a user's machine, in most situations that's very unlikely to be the case, and not the true intention of this API. Even if the vision is to create a font library-esque feature, the heart of the API would still be based on web fonts and not local fonts.

The only way I would agree with the second point is if the API looked at a user's machine and registered all of the installed fonts. But that seems overkill to me, and likely to produce inconsistent behavior since this will vary wildly user to user. There will also need to be font files that the site owner actually has the rights and proper licensing to use for users without the same system fonts.

Refocusing on the decision at hand, I don't strongly disagree with using "font", but I am bit torn and my personal preference is to use "web font". I'll try not to bike shed too much, but here is an outline of my thought process.

Even if the decision is to use "font" for class and function names, I'd still advocate for the API to be called the "Web Font API" and all of the documentation should use "web font" to be clear about what is happening. This does make the function names feel "wrong" and out of place. Classes and functions should be self documenting, and this would not be the case.

[colorful-tones]

My vote is for Font.

[ironprogrammer]

I'll admit that my eyes like the optimization of dropping "web" as redundant, but this is counter to the tradition of referring to fonts used on web sites as "web fonts". It's also notable that licensing from font providers/foundries make clear delineation between licenses intended for "desktop", "server", or "web" use.

IMHO it seems clearer to keep both words: "web font". This would be consistent with prior use, and perhaps help steer users/extenders away from unintentional license abuse.

[djcowan]

'Fonts' please. Although there are valid legal and practical arguments for being specific, we rarely make such distinctions elsewhere in life. Music is music, books are books, and colour is colour, regardless of medium, provider or context.

[askdesign]

My vote is for web font. It maintains consistency with other major vendors and prevents confusion with print fonts.

[ellenbauer]

+1 for Font

[hellofromtonya]

Even if the vision is to create a font library-esque feature, the heart of the API would still be based on web fonts and not local fonts.

The heart of the API is to generate valid @font-face CSS styles for all of the theme's defined "fonts" and user selected "fonts". I agree that vast majority of the usage will be for web font URLs. However, this is an API that creates the needed @font-face rules and thus should be open for users/extenders to register what is needed for their applications.

Looking at Authority Sites to help

Let's take a look at W3C CSS Fonts specifications to see if there's any guidance to help with the naming decision.

• In W3C CSS Fonts > 4.1 The "@font-face" rule:

The @font-face rule allows for linking to fonts that are automatically fetched and activated when needed. This allows authors to select a font that closely matches the design goals for a given page rather than limiting the font choice to a set of fonts available on a given platform. A set of font descriptors define the location of a font resource, either locally or externally, along with the style characteristics of an individual face. Multiple @font-face rules can be used to construct font families with a variety of faces. Using CSS font matching rules, a user agent can selectively download only those faces that are needed for a given piece of text.

* It says "font", not "web font".
* It talks about downloading the needed font (i.e. "user agent" = browser).
* It exists to not be limited by only what's on a given platform.

• In W3C CSS Fonts > 4.3.3.1 Local font fallback:

When authors would prefer to use a locally available copy of a given font and download it if it’s not,local() can be used.

* So extenders can define a fallback if the preferred font is not available for download.

What about mdn web docs?

• It defines @font-face as:

The @font-face CSS at-rule specifies a custom font with which to display text; the font can be loaded from either a remote server or a locally-installed font on the user's own computer.

• Notice the words used in describing src property:

The src CSS descriptor of the @font-face rule specifies the resource containing font data. It is required for the @font-face rule to be valid.

• Notice it does not reference "web font" when describing url() but rather uses "font resource":

[ format( # ) ]?
Specifies an external reference consisting of a <url>(), followed by an optional hint using the format() function to describe 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. If a user agent doesn't support the specified formats, it skips downloading the font resource. If no format hints are supplied, the font resource is always downloaded.

• Notice that it says: "it's common to use both":

It's common to use both url() and local() together, so that the user's installed copy of the font is used if available, falling back to downloading a copy of the font if it's not found on the user's device.

• Notice the @font-face page only mentions "web fonts" once (it's in the Notes section):

Web fonts are subject to the same domain restriction (font files must be on the same domain as the page using them), unless HTTP access controls are used to relax this restriction.

What's your point, Tonya?

IMO The API's name should reflect its vision and purpose. Thus, its name likely depends upon the answers to these questions:

• Should this API be limited to only web fonts (no local font definitions)?
• Should it fully support W3C @font-face definition to allow extenders to build what they need (i.e. local and/or web fonts)?

And then these for further thinking:

• If called "Web Fonts API", is this name clear enough that it also supports local fonts, not just web fonts?
• Conversely, if called "Fonts API" is the name unclear that it also supports web fonts, not just local fonts?

cc @aristath @jonoalderson @desrosj

[jonoalderson]

It should ultimately provide an abstraction framework for doing anything with fonts; regardless of the surface they're output to / designed for. Therefore, 'font' rather than 'web font'.

[hellofromtonya]

I'm throwing one more at us to consider 🤣

The result of the API is to generate @font-face CSS styles. Does "Fonts API" or "Web Fonts" API clearly describe the result of using the API?

[jonoalderson]

It might theoretically do other things / enqueue fonts in other ways in the future, I reckon? In which case, it's still a "fonts API", and the fact that that manifests as a @font-face declaration etc is just executional detail. The thing that the thing does is enable you to use a font. So, I think that's reasonably descriptive. Perhaps you could argue that this specific implementation is in fact a "Font Styles API", or "Font CSS API", which might later become a subset of a "Fonts API", but I'm not sure that's a helpful distinction at this level 🤔

[hellofromtonya]

That's true. It's an API. It will likely evolve over time to support the needs of the Font Library, users, and developers. And I like what you @jonoalderson said here as this is why it's needed and what it does:

The thing that the thing does is enable you to use a font.

[hellofromtonya]

The votes so far are:

• Fonts API: 5
• Web Fonts API: 3

@desrosj you had objections to calling it "Fonts API". What do you think today with the recent discussions? Would you be okay with it being more generically called the "Fonts API"?

[hellofromtonya]

PR #46749 renames the API to "Fonts API". It also deprecates the original webfonts public facing classes and functions as part of the temporary backwards-compatibility (BC) layer (ie to prevent sites from breaking while giving developers time to upgrade their code to the new API).

[simison]

industry standard refers to a font as "web font" when its font file is served from a web server to the browser.

Coming from print & digital design background, designers have also used "web font" to distinguish from "print fonts"; fonts optimized separately for screen use vs printing on paper.

I haven't been in touch with print design for many years anymore, but it seems like distinction and terminology has been slowly going away in design, with newer fonts more often being optimized for both screen and print use simultaneously.

Some further reading; https://creativepro.com/print-vs-web-fonts-what-s-the-difference/

Separate web/print optimization and licensing aspects are still often mentioned when describing the font (see e.g. Open Sans on Google Fonts).

Anyway, I also think simpler naming (just Fonts) is helpful and results to more readable class and function names. It also doesn't leave anyone guessing what "web" in APIs context actually means.

[peterwilsoncc]

I'm inclined to use font as it provides the most flexibility for any future spec/api changes but am pretty relaxed about the whole thing.

[jeffpaul]

Y'all can bikeshed all you want on what we call things here, with the exception of something user-facing within the editor in which case I strongly advocate for font as there seems to be little benefit in including the web adjective when all a user likely cares about is setting a "font" for their content. Whether that's a font file they're hosting, a file from somewhere on the web, or what-have-you including web would only seem to cause potential confusion to users within the editor.

[hellofromtonya]

Alrighty thank you everyone for weighing in on the renaming. The API will be renamed to Fonts API dropping the Web from the name. PR #46749 will be merged.