How should we vary font size with source and media queries?

[jamesgorrie]

Use-case

We would like to change the font size dependant on media queries. Pretty simple. We have come across two ways of doing this, both with drawbacks. I'll try outline those below.

1. Use static values to override font-size property

const heading = css`
	${headline.xsmall()}
	${from.tablet} {
		font-size: 28px;
	}
`;

Examples:

• support-frontend
• dotcom-rendering

Drawbacks:

• Values out of sync with design system
• Can create design chaos / discrepancies / debt
• Makes it hard for engineers why those values where used thus hard to change
• Potential to have font-size & line-height out of whack with Source

2. Re-apply the whole font CSS block

const heading = css`
	${headline.xsmall()}
	${from.tablet} {
		${headline.xlarge()}		
	}
`;

Drawbacks:

• re-includes the whole CSS block sending excess, unused bytes down the pipe, specifically the font-family e.g.

    font-family: GuardianTextSans, "Guardian Text Sans Web", "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;
    font-size: 1.5rem;
    line-height: 1.3;
    font-weight: 700;
    @media (min-width: 740px) {              
    	font-family: GuardianTextSans, "Guardian Text Sans Web", "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;
    	font-size: 2.125rem;
    	line-height: 1.3;
    	font-weight: 700;
    }

---

Thoughts on the above solutions

While Option 2. creates excess bytes, it feels the most sustainable in regards to keeping a consistent UX for our readers.

Option 1. Adds maintenance overhead and potential design debt whenever it is used.

Which should we use?

---

Thinking forward

If the decision above is that both are substandard, there are some other options we could explore.

Use explicit values from source

${textSans.xsmall()}
${from.tablet} {

	// as a generic API
	font-size: ${textSansSizes.xxxlarge}

	// or more explicitly to this case
	line-height: ${lineHeights.regular}
}

Drawbacks:

• This requires a client to know which line-height corresponds with which font-size for that specific font.

Exclude properties

${textSans.xsmall()}
${from.tablet} {

	// as a generic API
	${textSans.xxxlarge({ exclude: ['font-family'] })}

	// or more explicitly to this case
	${textSans.xxxlarge({ excludeFontFamily: true })}
}

Partial function

${headline.xsmall()}
${from.tablet} {
	// This method would exclude the `font-family`, and potentially `font-weight` properties
	${headlineSize.xlarge()}		
}

Drawbacks:

• All the above suffer from having to remember to use that specific solution when in a media query.

Allow source to take charge of media queries?

We could include media queries, ensuring that all of our designs scale the same way. You could make this backwards compatible by making it opt-in e.g.

${headline.xsmall({ withMediaQueries: true })}

// ... or more customisable
${headline.xsmall({ withMediaQueries: ['table', 'desktop'] })}

// ... or maybe xsmall makes no sense now?
${font.headline()} // gives us the whole shebang

Drawbacks:

• Inflexible - might be hard^* to agree on the values
• Adoption and migration

Benefits:

• We wouldn't need to think about these each time

^*Hard doesn't mean bad or we shouldn't try it

An all new API?

${headline({
  default: 'xsmall',
  tablet: 'small',
  desktop: 'xlarge',
})}

Drawbacks:

• Adoption and migration
  Benefits:
• Achieves all the things

---

There's a few other solutions I could think of - but maybe some guiding principles could be more useful:

• Don't include superfluous, repeated CSS
• Don't stray from Source CSS values - similar to the color-no-hex in dotcom-rendering
• We should not rely on an engineers memory for which font-api to use based on the context of being in a media or not

[sndrs]

Option 2. creates excess bytes

worth remembering they'll be tokenised and so gzipped away over the wire. and i'm pretty sure the setting an identical rule will not invalidate the existing one, so it shouldn't trigger a new paint (although the things that do change obviously will anyway)

[jamesmockett]

Use explicit values from source

The corresponding line heights are defined in the underlying design tokens so it's something we could expose which would allow you to do this:

${textSans.xsmall()}
${from.tablet} {
	font-size: ${textSansSizes.xxxlarge}
	line-height: ${textSansLineHeights.xxxlarge}
}

I quite like the idea of Source components supporting media queries though. I've run into similar issues where I've needed one of the layout components to have different spacing at different viewport widths. That's a change that would require a lot more thought though.

[SiAdcock]

We would like to change the font size dependant on media queries.

I'd love to know how designers (and especially @guardian/design-system) think about this problem. Is it common enough, and does it materialise with enough consistency, that an abstraction for it ought to be reflected in the design system? Are font size and viewport width values always dependant on the specific circumstance in which they are being used, or do they follow established rules e.g. body text is always 16px at desktop, 14px at mobile?

I've run into similar issues where I've needed one of the layout components to have different spacing at different viewport widths.

This is something we started to explore with the Column component, albeit with varying columns widths at different viewport widths. I'm not sure how configurable you'd want to make these layout primitives though, you might want to create a higher order component that controls spacing at varying viewport widths for the specific use case?

[akemitakagi]

Hello,
I am adding @HarryFischer here.
Shall we meet and discuss this?