Using brand font: only one box is behaving differently

[CharpentierLucas]

@Ricardo_Rodriguez

Does the set-up below override @font-family-serif?

Yup Note that this kinda works, but this could also create some weird behaviors for features supposed to use this serif font (none in XWiki Standard AFAIK). As I’ll detail later, trying out this change is also a great step towards finding where your oddity comes from

@Ricardo_Rodriguez

And now, what I’m getting in, now, two computers, both updated to the last-minute releases. One running Windows 11 PRO:

I didn’t check your result well enough at first. I assumed the font-family property was in line with the Fonts Used . I’m leaving a paragraph for the sake of keeping traces of my search, it could still end up useful at some point See the actual answer after this paragraph.

Good thanks!
Seems like the problem got solved by the small change, so it’s definitely a place in the code that uses this @font-family-serif variable. From your screenshot, we can be sure that it comes from a CSS ruleset on the whole body.

When I check the CSS source, I can see that this is close to a -webkit-tap-highlight-color property. This is quite specific, so I can search in the codebase: Code search results · GitHub

There’s only one result, and I can be sure that this CSS comes from this code:
xwiki-platform/xwiki-platform-core/xwiki-platform-bootstrap/src/main/less/scaffolding.less at 36aa8062822b50c8e488eb65a492ef1c0a48a114 · xwiki/xwiki-platform · GitHub

Soooo. It seems that our issue is that with Windows 11 PRO, @font-family-base takes the value of @font-family-serif instead of the default @font-family-sans-serif. To see where that comes from, I look for all the assignations of this LESS variable in our codebase. This is most likely with @font-family-base:<somethingafter>: Code search results · GitHub .
On this, I can see that the only assignations do not seem to care about the context, the only ones to a serif font are in the Bootswatch Colorthemes Journal and Readable.

After this research, it doesn’t seem like it’s an issue with XWiki Standard. I didn’t test any further so I cannot be 100% certain.

Soo, the Fonts Used is not the same as the font-family. This is weird. This looks like it might be the OS messing with our browser here. I tested with BrowserStack - Windows110 + Firefox 133:

We can see that, similarly, the default font is not the same as the one we have in style. Time to learn more about how this property works:

font-family - CSS: Cascading Style Sheets | MDN

Values are separated by commas to indicate that they are alternatives. The browser will select the first font in the list that is installed or that can be downloaded using a @font-face at-rule.

You should always include at least one generic family name in a font-family list, since there’s no guarantee that any given font is available. This lets the browser select an acceptable fallback font when necessary.

As far as I understand, your two machines do not have it downloaded, and cannot access it because you didn’t add a specific @fontface. Not sure if we have doc for this, if there is, we should fix it to avoid people doing the same mistake. I think you could solve your issue cleanly by adding a @fontface for Roobert into your colorTheme’s @lessCode property (or in any SkinExtensionSheet).

You might find some helping info at https://www.xwiki.org/xwiki/bin/view/FAQ/How%20to%20use%20a%20custom%20font%20in%20XWiki

Sorry for all the flailing around, I wasn’t very knowledgeable about fonts in CSS. It was a good opportunity to learn a bit more, thanks

@Ricardo_Rodriguez

A last funny thing I don’t understand. See below:

I created that Engulfing skin a time ago, but it is not currently set for any page. Do you understand why it appears on the URL?

Not sure why, this URL’s job is to retrieve the CSS for your page. In the request to get this CSS to your server, it provides some context elements so that it can be served a cached value if there’s one already on your server. For each CSS, your server caches it for each Skin and ColorTheme (and updates the cache as soon as the skin or colortheme is updated). It’s especially useful for LESS files where the compilation to CSS can take a very noticeable time.

It seems like your active skin is Engulfing. My guess is that it’s an extension of the DefaultSkin and it’s still somehow active even if you don’t have any customization. Here is what the URL on a standard instance I run locally looks like:

If you’re sure you use the Default Skin and not your custom one, this could be a small bug with the URL constructor.

---

Have a good day!
Lucas C.