how to handle fonts?

[wolfspyre]

I've recently uncovered a desire to enable the use of different fonts for different types of content within a site.

The request stemmed from a desire to have content authored by a specific contributor presented in a distinct font.
The use case expounded to reveal that it would be desirable to also have the main content font alterable based on category or context (shortcode)
I quickly realized that there's likely to be a lot of places where this could get messy, and that there is legitimately a reasonable request here, but achieving it elegantly is going to take some thought..

My first thought is that there's likely a decent way to hierarchically enumerate font preferences in config..

so defining some sort of clear default hierarchy which aligns to being overwritten via frontmatter somehow seems like a sane path, as doing this allows the 'current behavior' to be logically mapped as the 'default' preference.
This facilitates an opt-in/out of feature use so as to not break anything for existing congo inhabitants.

I could see it looking something like:

# hugo.yaml
"themeparams":
  - "hascustomfonts": "true"

hasCustomFonts
: : boolean if true, congo looks for a specified font file aligning to the default font families tailwind supports.
and will add them properly if found. By default, congo consumes the following font files to generate the site...

 - `/assets/css/fonts/_default/custom.woff`
 - `/assets/css/fonts/_default/default.woff`
 - `/assets/css/fonts/_default/sans.woff` 
 - `/assets/css/fonts/_default/serif.woff`
 - `/assets/css/fonts/_default/mono.woff`

I could see these being automagically fetched and consumed by the build process, or perhaps specified as a url. ¯\_(ツ)_/¯
)
I wonder if its good enough to START site-wide scope here, or if we need to go all the way to frontmatter support first for this.

I SUSPECT that only going coarse font-family deep will be too impactful, and not achieve the desired effect, and have a lot of unintended consequences ( but I don't really know or have a strong affinity to this suspicion )

I suspect that going to a frontmatter depth would likely mostly work.

I suspect there could be a need to inject some separation of classnames to delineate UI elements that should endure vs things that should be ubiquitously skinnable.... but as a thought exercise, I gave some thought to what a frontmatter scoped lookup might work like and what an implementation of it might entail

at a bare minimum, to even start doing any of this, it would mean

• 'add a check to see 'do we have a 'custom.woff' file at build-time? and if so
  • add it to the fonts classes in tw so as to have custom exist.
  • add to fonts in metadata
• add a font-custom hook/class/renderhook somehow to allow a quick toggle for a specific override in an easy way.

(This mechanism feels like it would offer most users' a one-off use-case of wanting a single custom font someplace on their site without having to change anything at all if they don't want anything to change)

and shouldn't increase build times really for anything that ISN'T using the features.
IDK what it would do to the ultimate build size; I don't THINK it would change much, I certainly don't anticipate it being a significant change... but .... stranger things have certainly happened ;)

that at least enables some dynamic injection of font selection into the build process and defines some isolation bounds...

next I'd envisioned some sorta use implementation like

# hugo.yaml
"themeparams":
  - "hascustomfonts": "true"
  - `hascustomfrontmatterfonts`: `true`

for which I thought this to be a decent spot to start.
it turns off a bunch of lookups in templates... (don't even bother firing a loop) as early as possible,
but it introduces a mechanism to inject some granular definition of font usage which can be consumed hierarchically

ie: all 'content/widgets' content could by nature of declaring some stuff in md, and adding a woff in assets:

So something like this as a branch:

# title /content/widgets/_index.md
---
cascade:
  - hascustomfonts: true
  - hascustomfrontmatterfontsfonts: true
  - customfonts: # this existing, means that something like the following logic is enabled
    - custom: "( look for : "thisresource" | default (`assets/css/fonts/widgets/custom.woff`|default( "`/assets/css/fonts/_default/custom.woff`") ) )"
    - default: "( look for : "thisresource" | default (`assets/css/fonts/widgets/default.woff`|default( "`/assets/css/fonts/_default/default.woff`") ) )"
    - sans: "( look for : "thisresource" | default (`assets/css/fonts/widgets/sans.woff`|default( "`/assets/css/fonts/_default/sans.woff`") ) )"
    - serif: "( look for : "thisresource" | default (`assets/css/fonts/widgets/serif.woff`|default( "`/assets/css/fonts/_default/serif.woff`") ) )"
    - mono: "( look for : "thisresource" | default (`assets/css/fonts/widgets/mono.woff`|default( "`/assets/css/fonts/_default/serif.woff`") ) )"
---

# My widgets are awesome
Please enjoy the awesomeness of my widgets in multiple font variations.

# title /content/widgets/mywidget/_index.md
---
title: "My Widget"
category: widgets
type: page
customfonts:
  - default: "assets/css/fonts/widgets/obnoxiouslyLoudFont41.woff" 
---

# my widget is amazeballs
check out my fancypants font disctinctiveness!

it also would, theoretically enable this without much config change by a user at all:

• add assets/css/fonts/_custom/plz_add_me.woff to /assets/css/fonts/custom.woff to user repo content

then

# content/posts/journeys/post42.md
---
title:"Post 42 ... how exciting"
slug: 'post42'
---

# post 42  {{: font-custom }}
Yes victoria, its finally happening. 
I think the doctors finally believe that I am sane.
I might just get out of here after all!!

(I think that's the syntax required to add a class to a md section? but I don't remember for sure off the top of my head)

This is just one of a few ideas I had around implementation....

I wanted to at least have some sorta idea to describe the desire / need... but I'm not particularly bound to this implementation...

I would really like to enable this functionality though. What do you think?