I have a question about Ghost’s custom fonts feature, specifically the “Heading font” and “Body font” options under Typography in the Design&Branding settings. Is there a way for a theme to detect whether the user has selected custom fonts for these options or if they have left them set to the “Theme default”?
I want to make my theme more flexible and fully compatible with the latest Ghost features while avoiding the unnecessary loading of fonts. My theme uses custom fonts that are not included in Ghost’s suggested font list, and I’d like to ensure that the theme only loads its custom fonts when the user hasn’t selected custom fonts from the admin panel.
This means that Ghost’s custom font feature, if used, takes precedence over my theme custom settings dropdowns for using system serif/sans/mono font stacks.
(If supporting older browsers, add an additional fallback to a Sass variable or hardcoded value.)
For conditionally loading the theme’s webfont, the best idea I have would be to load the webfont only after checking with JS whether the --gh-font-heading / --gh-font-body CSS custom properties are set. But there ought to be a better solution.
Since custom fonts are loaded via {{ghost_head}}, perhaps sometime in the future there will be an option to query the status of ghost head features using an {{#unless ghost_head.custom_fonts.body_font}}…{{/unless}} type syntax?
I’m not saying that including the information in @site might not be useful, but I think modern browsers are already able to selectively download fonts based on css font-face definitions that use fallbacks. Here is the network activity on my site :
local fonts:
Thank you for the input! I switched to local fonts, tested, and fully agree with you. Including the fonts on @site could be useful, but it’s not necessary for the case I described.
Hey everyone! As described @NickAbs, browsers selectively download the fonts based on the usage. With this advantage, we were able to add custom fonts support to official themes without doing any conditional work.
But the idea of including the data in @site could be valid. I think this being useful when conditionally preloading default theme fonts as the preloads happen regardless of the usage of fonts.
Hi! I agree with the previous posts here that using @site would be a great solution with a division for use in ‘body’, ‘heading’, as well as both. It’s great that the browser partially solves this problem, but I’m afraid that it still connects, for example, with Google’s CDN, which for many people might be unacceptable due to their privacy policies in a given country.
One of the great future options would be to see the ability to upload a custom font, and if that’s not possible, at least the option to choose a custom font from the fonts.bunny.net database.