Allow `govuk-typography-responsive` to be called with a 't-shirt size' for `$size`

[36degrees]

Context

We have the concept of 't-shirt sizes' (xl, l, m, s, xs) for text, for example headings, labels, legends, table captions.

They use consistent font sizes, but the mapping of t-shirt size to underlying font size is not defined anywhere in the codebase – it's just defined in each place individually and kept in sync.

For example, xl maps to a font size of 48 (on desktop):

https://github.com/alphagov/govuk-frontend/blob/34806961fffb5e3b43de9fbda5f9a08f376ec196/src/govuk/core/_typography.scss#L11-L19

https://github.com/alphagov/govuk-frontend/blob/34806961fffb5e3b43de9fbda5f9a08f376ec196/src/govuk/components/table/_index.scss#L53-L56

https://github.com/alphagov/govuk-frontend/blob/34806961fffb5e3b43de9fbda5f9a08f376ec196/src/govuk/components/label/_index.scss#L13-L16

https://github.com/alphagov/govuk-frontend/blob/34806961fffb5e3b43de9fbda5f9a08f376ec196/src/govuk/components/fieldset/_index.scss#L37-L40

We should consider updating govuk-typography-responsive to accept a t-shirt size, and automatically use the underlying size from the $govuk-typography-scale.

This would also allow calls to govuk-font to accept a t-shirt size, for example:

@include govuk-font($size: xl, $weight: bold);

This would also provide a way for components (ours, and downstream) to match with the heading sizes without, for example, needing to extend a heading class.

Alternatives

Without this, we need to keep the various 't-shirt-sized' components in the codebase in sync manually, and there is no easy way for consumers to use the xl, l sizing in their own codebase without manually keeping them in sync.

Additional information (if applicable)

This does introduce another (optional) layer of abstraction, but it feels like a useful one?

We might also want to consider extending the typography overrides to provide e.g. govuk-!-font-size-xl classes.

[36degrees]

Proof of concept branch here: https://github.com/alphagov/govuk-frontend/compare/poc-size-aliases?expand=1

[36degrees]

They use consistent font sizes, but the mapping of t-shirt size to underlying font size is not defined anywhere in the codebase – it's just defined in each place individually and kept in sync.

I thought that this was true, but in trying to move this forward I've realised that this is not the case!

The t-shirt sizes we use for the body (paragraph) classes and for heading captions are inconsistent with the t-shirt sizes used everywhere else:

Size	XL	L	M	S	XS
Labels	48	36	24	19
Legends	48	36	24	19
Headings	48	36	24	19
Heading Captions	27†	24	19
Table Captions	48	36	24	19
Body		24	19	16	14

† I think this is the only place in the codebase we use the 27px font size.

I think the heading caption classes can be explained as they are designed to be paired with a heading of the same size, and so renaming them to reflect the text size of the caption would make them harder to use correctly.

However the body text sizing just feels inconsistent to me, and I'm not sure it makes sense to expose the t-shirt sizes as an abstraction whilst that inconsistency exists.

It might potentially make sense to bring the paragraph classes 'in line' as part of #2418? It would however be a breaking change so we'd need to assess if it was worth it or not.

Size	XL	L	M	S	XS	XXS
Headings etc	48	36	24	19
Body (Before)		24	19	16	14
Body (After)			24	19	16	14

Given the discussion in #2418 it seems likely we'd just drop the XXS / 14px entirely.

Alternatively we could:

• ship this even though the inconsistency with paragraphs exists
• do nothing

[edwardhorsford]

I don't think it makes sense to align body text tshirt sizes with heading sizes.

It's expected that body text be smaller than headings. I think it could be counterintuitive for the standard body size to be body-s. In css, m is often the default size. I might expect body-l to be the larger size - but in fact it doesn't exist!

Aside: my sense is that the various other body sizes aren't often used.

Right now you can obviously pair a caption-m with a heading-m. In this new world I guess you'd have to pair a smaller caption to get the same? You'd need to pair caption-s with heading-m? For new services this should be no problem - but I worry this could cause quite a bit of work to get existing services to update - you might have to go through every page one by one to fix?

[36degrees]

I don't think it makes sense to align body text tshirt sizes with heading sizes.

It's expected that body text be smaller than headings. I think it could be counterintuitive for the standard body size to be body-s. In css, m is often the default size. I might expect body-l to be the larger size - but in fact it doesn't exist!

The way I've been thinking about this, there are (at least) two mental models for sizing:

• Size is relative to 'the thing' (in the same way that a large mouse and a large elephant are not the same size)
• Size is applied constantly across the system

If we're thinking only about body sizing vs headings then I'd agree that it probably makes more sense for us to be using the first model.

However, everywhere else we've intentionally tried to 'uncouple' sizing from semantics, because when someone is thinking about the visual hierarchy of the page, it's useful to be able to think about the sizing separately to whether a specific thing is a heading, label or legend (or a paragraph!):

So, at the minute, we're mostly following that second model (sizing is consistent), except for the body sizing. If we fix that, IMO it becomes a lot easier to explain how this works, and easier to apply once you've learned it.

Aside: my sense is that the various other body sizes aren't often used.

I have no data to back this up but anecdotally I'd agree, and actually I think that'll make this change much easier for most teams.

We'd update the existing govuk-body and govuk-body-lead aliases to point to the 'new' size – so service teams will only need to make changes at all if they are using the govuk-body-l, govuk-body-m, govuk-body-s or govuk-body-xs classes directly.

There's a presentation I played back to the team back in July that goes into a bit more depth on the thinking behind this change: https://docs.google.com/presentation/d/1vZPI77p9WFhLQx2bEMA80RoEBblaP0m1B5sOxtc4VP0/edit?usp=sharing

Right now you can obviously pair a caption-m with a heading-m. In this new world I guess you'd have to pair a smaller caption to get the same? You'd need to pair caption-s with heading-m? For new services this should be no problem - but I worry this could cause quite a bit of work to get existing services to update - you might have to go through every page one by one to fix?

I agree – I don't think we intend to change the caption classes for that very reason. I appreciate that does seem to contradict at least some of what I just said above, but I think it makes some sense as they are always intended to be use in a particular way where they are paired with a heading of the same size.

[colinrotherham]

@36degrees Oops, I've accidentally made this possible in https://github.com/alphagov/govuk-frontend/pull/4713 😆

E.g. Updating the new loop in 1ed26b0 to check for an alias