[dev-22246] Fix where the wrong font family was being used for paragraphs and links

[alpower]

We noticed 6 weeks ago that for the themes that had secondary fonts, a bold version of the font was being used.

Turns out with a bit of digging, it's the primary font always, which is why it's always in a bold weight, which is wrong.

But following a thread in the code, looking at what's being set in themes, if a single font is used, it get's set for both primary and secondary fonts.
The fonts are being generated and included correctly (using a single font or two fonts):

function getSecondaryFontFamily(font: Font): string {
    switch (getRelatedFont(font)) {
        case Font.ALEGREYA_SANS:
            return FONT_FAMILY[Font.ALEGREYA_SANS];
        default:
            return getFontFamily(font);
    }
}

The fonts are being set correctly

'--prezly-font-family': getFontFamily(font),
 '--prezly-font-family-secondary': getSecondaryFontFamily(font),

and used for the body correctly:

body {
    font-size: 16px;
    font-family: var(--prezly-font-family-secondary);
    color: var(--prezly-text-color);
    word-break: break-word;
    background: var(--prezly-background-color);
}

however when applied to p and a tags they were being set like this:

p,
.paragraph {
    @include typography.paragraph;

    & {
        font-family: var(--prezly-font-family);
    }
}

a {
    color: var(--prezly-accent-color);

    & {
        font-family: var(--prezly-font-family);
    }
}

...which was incorrect. Changing this to --prezly-font-family-secondary for p and a tags ensures the right font is used for body copy, irrespective of whether it's a one or two font theme, and all the weights get pulled in correctly.

and adding the correct font for links within p tags means the story content gets the right font, while links in the header stay the primary font.

// ensure paragraphs with links are styled correctly, but things like header links are not affected
p a {
    font-family: var(--prezly-font-family-paragraph, var(--prezly-font-family-secondary));
}

Before

After

[fgyimah]

Good digging @alpower 👍🏾! one small feedback

[fgyimah]

Should we apply the secondary font on this line instead of introducing a new p a {} rule?

[alpower]

No - see my comment below in the code. The primary font is for the headlines and things in the nav bar. The secondary font is for the body. If you apply it here it affects all the links - including those in the navbar like Logo and navigation (which are also links).

So this has been done to make the header links primary font, and then a more targeted p a the secondary, ensuring it works with existing themes with a single font as well.

This is the problem of styling selectors based on raw elements and for me is a bit of a code smell as hard to understand (as demonstrated by your comment). Wonder what @e1himself thinks.

[e1himself]

I'd say it's weird that we first apply the bolder font weight to all links and then override it for paragraphs.

I'd very much expect it to apply the baseline style (i.e. the in-paragraph presentation) to all links and only lift that to the bolder font selectively where necessary.

The questions that reveal what's wrong with the approach currently suggested in this PR:

1. What about links inside quote blocks? (they're wrapped with blockquote and not p).
2. What about links inside lists (they're not wrapped with p either, AFAIK).

[alpower]

That's what I'd hoped you'd say.

The questions that reveal what's wrong with the approach currently suggested in this PR

This is not something I introduced by the way but an existing problem. I would suggest we do exactly what you say - not style links as bold, but apply it as the default (not bold) and then style it bold where needed. I need to do some more digging then as to how this works.

[e1himself]

👍

Watch out, Jesse touches this part in his other preview-related PR to Bea:
https://github.com/prezly/theme-nextjs-bea/pull/1412/changes#diff-ba217e4e809e5395dc9662b2c8f787b46d40855d74f96f58b2be7dd0140f1bcd

There's a chance it's fixed there.

[alpower]

@JesseWynants this is a unfinished PR to fix an issue with those themes that has 2 fonts, where we currently mistakenly use the header font for the body text (read main PR desc). While this PR still needs work (it's approach isn't quite correct) Ivan noticed that it touches a lot of the same code that your big font change PR does. Do you want to address this issue in your bigger PR? I don't want to make changes that impact what you are working on.

[e1himself]

I'd say it's better to merge the big one first and then get back to this problem -- if it's not fixed yet, then file a PR (a new one, of update this existing PR).

[JesseWynants]

I noticed this issue as well when working on the custom fonts, but just decided to keep the existing behavior. So I will merge the big one first (a bit of work to do on that), and then we can fix this more clearly.

[alpower]

@JesseWynants I've merged in your custom font work to this branch, and my fix still applies, so I've amended my fix so it's compatible with your changes. Tested things render OK locally. Can you give an approval? I don't think I need to update version numbers for anything.

[alpower]

@JesseWynants addressed Quality bot's review comments. I'm OK to merge this if you approve it.

[JesseWynants]

hey @alpower good, maybe ask QualityAssistant for a review on this PR as well, usually he clears some stuff first 🙂

[prezly-quality-agent]

Review — Hermes

The core fix is correct: p/.paragraph was falling back to --prezly-font-family (the primary/heading font, which is why body copy rendered in the bold primary face). Pointing the fallback at --prezly-font-family-secondary is the right call and matches what body already uses on line 5.

One 💡 below — nothing blocking.

💡 The p a rule is likely redundant

a already resolves to font-family: inherit (line 49-55), so a link inside a paragraph already inherits the paragraph's now-corrected --prezly-font-family-secondary. The new p a rule sets the same value it would inherit anyway. It works, but it's dead weight unless there's a case where the inherit chain breaks (e.g. a link directly under body but not under p, which this rule wouldn't touch either). If you've confirmed a real case where inherit wasn't doing the job, ignore this — but worth a sentence in the PR on what it fixes that inheritance didn't.

✅ Looks good

• Scoping to p a (not bare a) correctly leaves header links alone — good instinct, and the comment explains it.
• Keeps the --prezly-font-family-paragraph override hook intact.

---

Reviewed by Hermes Agent

[JesseWynants]

Good stuff.

We should also fix this for the other custom themes that have fonts ability, only tomorrowland and bea-reverse