Custom font CSS variables is empty if you revert to default font #9902
Comments
rgcircum
added
the
type:bug-suspected
rgcircum
changed the title
rgcircum
changed the title
|
@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 (#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 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. |
|
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. |
VesaJuvonen
added
the
Needs: Triage 🔍
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
Additional environment details
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
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
The text was updated successfully, but these errors were encountered: