Add support for font family stacks

vladolaru commented 4 years ago

Just like we have now for standard fonts (e.g. Arial, Helvetica, sans-serif), we should consistently support font-family having a value defined as a font stack for fallback purposes.

Right now, besides standard fonts, we don't support such a behavior, all font-family values are expected to have just a value.

By switching to a list value for font-family we could accommodate single and multiple values.

@razwan @georgeolaru What say you?

georgeolaru commented 4 years ago

@vladolaru that would be a great improvement in building a resilient frontend experience.

As the font stack is highly dependent on the main font, I would suggest starting the implementation with the fonts from Pixelgrade Cloud Fonts — the Google Fonts ones already have the generic name embed and they are already too many to handle by ourselves (a few hundred).

My proposal is to split the font declaration into three parts:

font-family: (1)[The Desired Font], (2)[Mac-Fallback, Win-Fallback], (3)[generic-name];

The desired family-name: Reforma1969
The main fallback list consisting of fonts bundled with the operating system: Arial, Helvetica
A generic name as a last resort in the fallback mechanism: sans-serif or the new system-ui

@razwan Are there any options to have two new fields beside the main one? Or the font stack should be directly embedded in the loaded stylesheet?

@vladolaru Hope it helps and I'm willing to explore more to find a clean and simple solution for this matter.

razwan commented 4 years ago

@georgeolaru it feels like I'm missing something. I think what @vladolaru is saying is that we need to update the Font Family field for the fonts we've added with an entire stack of fonts instead of just one.

georgeolaru commented 4 years ago

@razwan I understand that we need to extend the "Font Family" field — but currently, the field supports only one value, not an entire stack.

My proposal of multiple fields would come in handy to standardize the declaration as there are not many fallback fonts available (eg. we could even have a select field for "Fallback Fonts" with 5-10 stacks that could be enough for most of the cases).

razwan commented 4 years ago

@georgeolaru my guess is that we're not going to have to select from 5-10 stacks because they're merely fallbacks and we will have only 4 stacks for: serif, sans-serif, monospace, cursive. And these could be automated based on a tag set on the Font post type.

@vladolaru I'm still confused with this proposal and I'm concerned that we're exploring some over complicated solutions.

Could you please shed some light on what is the actual issue here and if there are any technical limitations that would allow the Font Family field to take a value like League Spartan, sans-serif?

Thanks!

georgeolaru commented 4 years ago

Thanks, @razwan! I guessed that the font stacks would need to get more complex due to the fonts used. So besides the four stacks mentioned which I put it under the generic fonts, there would be a few more in-between like League Spartan, Gill Sans, Tahoma, sans-serif.

@vladolaru please confirm about which way to pursue next. I'm satisfied with both of them: the simple and straightforward one mentioned by Razvan, and the complex one suggested by me.

vladolaru commented 4 years ago

@georgeolaru @razwan There is some confusion, and I will try to shed some light.

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. George's proposal breaks down the stack into 3 parts: the defined (cloud) font family, closely related fallbacks, and generic fonts. 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. 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 (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. 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. Theme fonts don't have that.

As 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. This way we could identify paths to proceed with more confidence.

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. But that is up to me and it is doable. 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).

I hope this helps.

georgeolaru commented 4 years ago

Thanks, @vladolaru for stepping in! I'm worried that I'm still confused.

I think if we can define some actionable steps and start the implementation, we will figure it out the rest of the details on the go.

In my opinion, it could be easier if we can split everything into two systems: input and output.

The "input" is the [font definition]

The font stack should be derived from the Main font (no matter if it's defined in the Pixelgrade Cloud or stored in Google Fonts as it's always loaded via Web Font Loader).

(1)[The Desired Font] < Pixelgrade Cloud or Google Fonts (2)[Mac-Fallback, Win-Fallback] < system fonts only (3)[generic-name] < system-ui, serif, cursive

The "output" is the [font declaration] handled in Customify

Note that the definition of font-family in CSS is a property that specifies a prioritized list of one or more font family names and/or generic family names for the selected element. via Mozilla.

font-family: (1)[The Desired Font], (2)[Mac-Fallback, Win-Fallback], (3)[generic-name];

Let me know if it makes any sense. If so, I suggest to discuss and answer the first question:

1. Where do we define the font stack for each font loaded?

vladolaru commented 4 years ago

Ok @georgeolaru . We will go this route:

we will not modify any configurations in themes or font palettes
we will add the two additional fields to cloud fonts, and based on those we will expand, in-place, the selected font family with the resulting font stack( e.g. Open Sans becomes Open Sans, Helvetica, Arial, sans-serif)
we will automatically deduce the appropriate font stack for Google fonts based on their category

After these, we will see what next steps we need to take.

georgeolaru commented 4 years ago

Awesome @vladolaru! I'm glad we now have a clear path to move forward.

As it's not a top priority for us, I suggest coming back to it whenever we have some time.

vladolaru commented 4 years ago

Closing here also!

pixelgrade / customify