[Fonts API] How to handle duplicate font variations #40288
Description
Part of #41479.
What problem does this address?
It's not clear to the end-user how the Fonts API will behave regarding the registration and enqueueing of duplicated font variations.
Only enqueued fonts are added as inline styles in the front-end.
API scenarios
Trying to register a font face that was already registered
wp_register_fonts(
array(
'Roboto' => array(
'font-family' => 'Roboto',
'font-style' => 'regular',
'font-stretch' => 'normal',
'font-weight' => '400',
'provider' => 'google',
),
)
);
wp_register_fonts(
array(
'Roboto' => array(
'font-family' => 'Roboto',
'font-style' => 'regular',
'font-stretch' => 'normal',
'font-weight' => '400',
'provider' => 'local',
),
)
);Which one should take precedence? The one that already exists, or the one that they're trying to re-register?
Trying to register a font-family that was already enqueued
wp_register_fonts(
array(
'Roboto' => array(
'font-family' => 'Roboto',
'font-style' => 'regular',
'font-stretch' => 'normal',
'font-weight' => '400',
'provider' => 'google',
),
)
);
wp_enqueue_fonts( array 'Roboto' ) );
wp_register_fonts(
array(
'Roboto' => array(
'font-family' => 'Roboto',
'font-style' => 'regular',
'font-stretch' => 'normal',
'font-weight' => '400',
'provider' => 'local',
),
)
);What should happen?
- Should we dequeue the enqueued font and add the newly registered font to the registered fonts list?
- Should we just ignore the re-registration attempt?
- Should we keep the enqueued face there and add the newly registered font to the registered list?
Scenarios including theme.json
After #39988 gets merged, new scenarios will come up now that we're considering theme.json as the source of truth for themes that are using this file.
Trying to register and enqueue, through theme.json, a font face that was registered programmatically
In PHP:
wp_register_webfont(
array(
'font-family' => 'Roboto',
'font-style' => 'regular',
'font-stretch' => 'normal',
'font-weight' => '400',
'provider' => 'google',
),
);In theme.json:
{
"fontFamily": "Roboto",
"slug": "roboto",
"name": "Roboto",
"provider": "local",
"fontFaces": [
{
"fontFamily": "Roboto",
"fontWeight": "400",
"fontStyle": "regular",
"src": "file:./assets/fonts/Roboto-Regular.ttf"
}
]
}Should we de-register/override the programmatically registered font face? Remember that we're trying to make theme.json the source of truth.
Current behavior in #39988: both are added to the registered list.
However, the programmatically registered webfont is the one that gets enqueued. That's because it's found first when looking for registered font faces to enqueue and their attributes are equal (the provider is not taken into account in the comparison).
Trying to register and enqueue, through theme.json, a font face that was enqueued programmatically
In PHP:
wp_register_webfont(
array(
'font-family' => 'Roboto',
'font-style' => 'regular',
'font-stretch' => 'normal',
'font-weight' => '400',
'provider' => 'google',
),
);
wp_enqueue_webfont( 'Roboto' );In theme.json:
{
"fontFamily": "Roboto",
"slug": "roboto",
"name": "Roboto",
"provider": "local",
"fontFaces": [
{
"fontFamily": "Roboto",
"fontWeight": "400",
"fontStyle": "regular",
"src": "file:./assets/fonts/Roboto-Regular.ttf"
}
]
}Should we dequeue the programmatically enqueued and instead register + enqueue the theme.json face?
Current behavior in #39988: both are enqueued.
Additional information
This problem is not a blocker for #39988 since that PR addresses a different matter. The above-mentioned behavior is already happening in trunk and #39988 is not the appropriate place to fix it.