Thanks, for stepping in! I'm worried that I'm still confused. It also adds the benefit of standardizing the font-family property value in line with standard fonts (these were the only ones using font stacks). Now the bigger issue is in Customify where I would need to refactor the logic handling font families to handle a list of font families not a single font family like we do today. This way we could identify paths to proceed with more confidence. Theme fonts don't have that.Īs a conclusion, we should switch to thinking about font definitions that allow the system to offer (in selects) and load the font files (via Web Font Loader or from the system), and font-family property values. Google fonts have some categories attached and we could use those to automatically "expand" each font family in a stack, but that would be an automated approach that could only take us so far. We could (maybe should) define font stacks (regardless of cloud or google fonts) in font palettes and theme configurations, by hand, since that is where we have the most context. So, it's not an option to add the font stack inline in the font family field for cloud fonts definitions, as Razvan suggested, because we are not defining a font-family CSS property value there, but a font to be made available. We could send these additional details with each cloud font and "expand" it in place wherever we will find it in font palettes or theme configurations. George's proposal breaks down the stack into 3 parts: the defined (cloud) font family, closely related fallbacks, and generic fonts. When it comes to cloud fonts, the font family value can't be polluted with other details because that is the font family targeted by Web Font Loader.
There is some confusion, and I will try to shed some light.
0 kommentar(er)
