SharePoint
Custom font CSS variables is empty if you revert to default font
Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
Windows
What browser(s) / client(s) have you tested
- [ ] 💥 Internet Explorer
- [ ] 💥 Microsoft Edge
- [ ] 💥 Google Chrome
- [ ] 💥 FireFox
- [ ] 💥 Safari
- [ ] mobile (iOS/iPadOS)
- [ ] mobile (Android)
- [X] not applicable
- [ ] other (enter in the "Additional environment details" area below)
Additional environment details
- All latest browser
- SPFx version : 1.19.0
- Node.js : 18.x.x
Describe the bug / error
If you choose a custom font from Font Customizer (Settings => Change the look => Font (Preview)) after validate new font and if you revert to the Default font, the new CSS Variables genrated is empty (see screenshot)
Steps to reproduce
- Change the font (Settings => Change the look => Font (Preview))
- Validate
- Return to Setting and select the default font
- Validate
- See the CSS variables generated on browser devtools (ex: search fontFamilyCustomFont800)
Expected behavior
Empty CSS variables should not be generated, because if they are called in a CSS, it will be considered as existing, but since it is empty, it will be Time New Roman (or the browser's default font) that will be taken into account, and not the fallback fonts defined in the CSS
@rgcircum You are correct this is from my perspective a bug that I encountered previously too. The only since SharePoint and Fluent Design as well do not have a proper font definition on the body tag, you will fallback to the browser default.
The only workaround I can think of is to set a style to the DOM element.
this.domElement.style.fontFamily = 'var(--fontFamilyBase');
fontFamilyBase is (should) be always set and therefor it won't fallback to Times New Roman.
Remember it is still in PREVIEW but I hope this behaviour changes in future.
The problem is not with fontFamilyBase which is always generated correctly, but with custom variables added by the font override feature.
If you define a style like this (this is just an example):
p {
font-family: var(--fontFamilyCustomFont800), "Segoe UI", "Segoe UI Web (West European)", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;
}
or
p {
font-family: var(--fontFamilyCustomFont800, "Segoe UI", "Segoe UI Web (West European)", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif);
}
If fontFamilyCustomFont800 is generated empty, it will be used in priority and will ignore the fallback
I am testing this feature that has been awaited for a long time by many of my customers (even if it is still in preview), I am reporting bugs in case the SPFx team did not see these bugs before the GA.
I think it is not very useful since there is never any response from the MS teams ... it is hopeless.
As for this one (https://github.com/SharePoint/sp-dev-docs/issues/9830) and many others.
Thank you for answering each time, I feel less alone :D
You should define the fallback like this.
p {
font-family: var(--fontFamilyCustomFont800, --fontFamilyBase)
}
However, since the first value then becomes invalid it the inheritance falls through up to the <body> tag, which in SharePoint has the browser default 'Times New Roman' define.
When you have the, always working, font family definition on the root of your web part. The inheritance goes only to the always working base font which is then Segoe UI.
You cannot solve the issue that the font family definition on your web part get's invalid but you stop the inheritance right at the root of your web part. So instead seeing Times New Roman you will see still Segoe UI.
See: https://mdn.io/font-family at the formular definition.
In a Fluent UI 9 + custom provider context, it doesn't work, even by mixing the 2 solutions you proposed.
To solve a bug of overloading of FUI9 controls in a SPFx use (Dropdown, Button ...), I am forced to redefine the variable --fontFamilyBase provided by the custom provider in my WebPart as indicated in the FUI9 doc (https://react.fluentui.dev/?path=/docs/concepts-developer-theming--docs)
export const customLightTheme: Theme = {
...webLightTheme,
fontFamilyBase: 'var(--fontFamilyCustomFont800, "Segoe UI", "Segoe UI Web (West European)", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif)',
};
overloading --fontFamilyBase allows the font chosen by users to be applied correctly to all FUI9 controls without having to redefine them one by one.
Ideally, MS would overload --fontFamilyBase with the right font and not generate empty variables;
Well, anyway, this is clearly a bug, using FUI9 and the font overload is absolutely not usable at the moment.
@rgcircum --- Reason 1,483,989 why @StfBauer and I created/use/and continue to maintain hTWOo. But yes, the left and right hands are not talking to each other.
Yes, you did a very good job, but unfortunately, it is not complete enough for my needs.
hTWOo is very good for small to middle components, but I work mostly on big applications.
You do not have a complete enough equivalent for lists for exemple (eg: Table from hTWOo vs DataGrid from FUI9 or DetailsList from FUI8)
@rgcircum thanks for your feedback - we are always open for suggestions. Challenge accepted!!!
Hello @rgcircum, We were able to reproduce the issue, and we are investigating it. We have logged this as a bug, and our engineering team will look into it. Thank you!
Thanks @Amey-MSFT, There is also this bug that is not fixed and that blocks the overloading of fonts coming from the Brand Center on dialog boxes and all floating elements : https://github.com/SharePoint/sp-dev-docs/issues/9830
Thanks for raising this issue. After internal alignment with respective engineering teams we've concluded the expressed behavior is unfortunately not something we'll likely change and therefor this issue is being closed. Thanks for your understanding.
I think this means we really can't use custom fonts in our SPFx solutions. @StfBauer please confirm or refute. Do we have a work around?
@juliemturner It is possible to use fonts, but only in WebParts, without PopUps or other floating elements. You cannot use them in custom headers/footers and perhaps in other places.
@jansenbe Are you really an engineer?
@rgcircum I know @jansenbe personally and yes, he is absolutely an engineer and incredibly smart. Whatever the limitation is it's not for lack of his knowledge. While I feel the frustration the sentiment wasn't really necessary.
With regard to using custom fonts, thank you for your insight, but I'm specifically referencing the work I do with @StfBauer on our open-source solution hTWOo.
I recently talked about custom fonts and the brand center. We can and will incorporate it in hTWOo.