Brand center fonts are not undefined when setting site collection font back to default

[mbice]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

None

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• SPFx 1.21.1

Describe the bug / error

Hi,

We have noticed that the default state of brand center custom font CSS variables is different depending on whether or not a font has ever been applied. It is undefined when no custom fonts have ever been applied. Once you apply a font and then reset it back to default, they are still present, but empty. Expectation would be that when resetting back to default those variables are undefined. This helps us with custom solutions that have custom fonts defined as a CSS variable fallback.

Thanks!

Steps to reproduce

1. Upon initial loading of a page where no fonts have ever been applied, all the CSS variables (e.g. --fontFamilyCustomFont1600, etc) are undefined (as expected). This helps us with our custom solutions where we may have custom fonts defined as a fallback.
2. Apply a custom font package from the brand center and you see all the CSS variables defined (as expected).
3. Set the site collection font back to "Microsoft default: Segoe UI" and on page load we can see that the font CSS variables are not undefined, but still populated as empty. Because they are empty, our fallbacks don't apply correctly and it ends up inheriting default fonts.

Expected behavior

Our expectation would be that when resetting fonts back to default that the CSS variable behavior is the same as the initial state where those variables are undefined. This ensures we have consistent fallback behavior in our custom solutions for the "default" scenario where no custom fonts are actually being applied through a font package.

[Ashlesha-MSFT]

Hello @mbice,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[Ashlesha-MSFT]

@mbice,
Thanks for reporting the font variable behavior — I’m currently trying to reproduce it.
I’ve applied a custom font from Brand Center, but when I inspect the CSS variables using:

I’m still seeing for all variables, even after applying the font. Could you please confirm if there’s anything specific I might be missing in the setup or steps?

Appreciate your help!

[mbice]

@Ashlesha-MSFT thanks for looking into this. Here's how I'm seeing the issue on my side.

1. Add a text web part
2. Inspect the text and look at Elements > Styles tab in dev tools. Find where the font-family is defined and when you hover over the --fontFamilyCustomFont900 variable it's "not defined", which is expected default behavior.

3. Apply a font package other than the default (doesn't have to be a custom added one - even applying one of the other out-of-the-box font packages will reproduce the bug).
4. Inspect text again and in dev tools the CSS variable is now populated. e.g. here is what I get when I hover over the CSS variable with the out-of-the-box Verdana/Georgia font package applied.

5. Now reset font back to "Microsoft default: Segoe UI". Expectation would be the CSS variable would go back to the same as step 1 above. But instead the CSS variable is still populated, but with an empty string. This causes the fallback in that CSS variable to not be invoked, which for custom solutions where we have a different font we may want to apply as a fallback, it doesn't work and the inherited font from higher up in the DOM tree is used, instead.

Hope that helps!

[Ashlesha-MSFT]

@mbice,
Thank you for the detailed reproduction steps!
I was able to reproduce the issue described, and can confirm the behavior is reproducible in my environment.
We will log this as a bug, and our engineering team will look into it.

[Ashlesha-MSFT]

@mbice,

I noticed this bug has been marked as Done on the engineering side.
Could you please help confirm whether the issue is now resolved on your end?

Thanks!

[mbice]

@Ashlesha-MSFT just verified this is now working as expected on both targeted and and standard release tenants. This is great, thanks!