search

SharePoint / sp-dev-docs

SharePoint & Viva Connections Developer Documentation
https://docs.microsoft.com/en-us/sharepoint/dev/
Creative Commons Attribution 4.0 International
1.25k stars 1.02k forks source link

Custom font CSS variables is empty if you revert to default font #9902

Open rgcircum opened 2 months ago

rgcircum commented 2 months ago

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)

image

Steps to reproduce

  1. Change the font (Settings => Change the look => Font (Preview))
  2. Validate
  3. Return to Setting and select the default font
  4. Validate
  5. 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

StfBauer commented 2 months ago

@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.

rgcircum commented 2 months ago

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

StfBauer commented 2 months ago

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.

image

rgcircum commented 2 months ago

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.

juliemturner commented 2 months ago

@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.

rgcircum commented 2 months ago

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)

StfBauer commented 2 months ago

@rgcircum thanks for your feedback - we are always open for suggestions. Challenge accepted!!!