Better define relationship between headings, error message and hints

[36degrees]

This decouples the markup of the label as the page heading from the styling, by removing any styling from the heading and delegating all styling responsibilities to the label.

This:

• introduces new 'variants' for legends and labels (e.g. govuk-label--xl, govuk-fieldset__legend--xl) that make the legend or label the same size and weight as the equivalent heading
• introduces a new parameter legend.isPageHeading for fieldsets, which defines whether the legend text should be wrapped in an h1 – <legend><h1>Have you changed your name?</h1></legend>
• introduces a new parameter isPageHeading for the label component, which defines whether the label itself should be wrapped in an h1 – <h1><label>What is your National Insurance number?</label></h1>
• adds styling for h1s in both contexts which effectively 'reset' the h1 such that it has no effect – i.e. the isPageHeading flag should have no effect on the styling of the question.
• updates components that call the label or fieldset component to pass these parameters.

You can see all combinations of here.

[NickColley]

Not blocking (since can be changed later) but this exposes internals (#460)

[36degrees]

It's consistent with the way we do it everywhere else at the minute.

[NickColley]

If we used the core heading classes would we need to do this?

[kr8n3r]

i prefer that it's separate.

[36degrees]

The intention behind this is to decouple the idea of what's a heading with the visual hierachy on the page - reframing the problem so that heading-xl is 'a heading which is extra large', and label--xl is 'a label that is extra large'.

You can therefore have an medium label which is not a heading, and you could also (theoretically) have a label with no additional styling that is a heading. Using the core heading classes muddies the semantics again.

There are some additional benefits in that we don't actually want any of the margins that the core heading classes give us, so at the minute we have to override them - whereas this allows us to define them separately.

[NickColley]

Think it's important to think about how the user views these, both label--xl and heading--xl is the same thing visually. heading--xl shouldnt concern itself about semantics, but only how it presents as a heading.

I'm mostly concerned about:

• how we keep the two in sync
• impact on file size
• another interface to learn

That said, if it's not easy to use the core classes, this seems a reasonable approach.

Other benefit is that decoupling them makes them easier to delete.

[36degrees]

But my comment was pretty much entirely about how we want the user to think about them – if they're thinking of legends and labels as headings when they are not headings then that is not helpful – understanding how to mark them up becomes a lot simpler if you can keep the distinction clear.

Visually, it's true that they're the same font size and weight, but the margins are completely different. We did go down the route of adding a mapping of xl, l to their respective font sizes, etc but abandoned it as it seemed premature at the time.

I'd like to avoid blocking this PR if possible given how long it's taken to get this work done, but adding a mapping or some sort of abstraction is definitely something we can revisit later.

[NickColley]

I should have prefixed my comment with that it wasnt blocking.

Just wanted to understand that using the core classes was not possible, since I think this is very complex to understand.

[36degrees]

It's totally possible, but I don't think it's actually desirable in this case, for the reasons outlined above.

[kr8n3r]

changelog

[kr8n3r]

happy with this :)

[36degrees]

@igloosi happy with c13793a?

[kr8n3r]

👍