Header navigation margins option 2

[frankieroberto]

This is an alternative to #999 which achieves the same outcome (aligning the navigation items with the rest of the header) but in a different way, by removing the horizontal padding inside the links and having horizontal margin instead.

This means a slightly reduced target area for each link, but they should still be well above the minimums for usability and accessibly (so long as the link text is 4 or more characters).

It also means that the focused item is also aligned with the header.

This is similar to the approach of the GOV.UK Design System's new service navigation component, although that has a shorter focus style.

Current	Proposed

[paulrobertlloyd]

I think if you were going to use this approach, you’d still want some inline padding, say 2-4px, else it looks a bit odd, perhaps broken.

[frankieroberto]

@paulrobertlloyd:

I think if you were going to use this approach, you’d still want some inline padding, say 2-4px, else it looks a bit odd, perhaps broken.

Yeah, I think I agree. The GOVUK one doesn't do that, but possibly the Transport font has a tiny bit more space in the characters compared to Frutiger?

I also kept the minimum margin between the items the same as the current padding-based spacing I think (nhsuk-spacing(6)) but perhaps it could be a little bit less.

[anandamaryon1]

@frankieroberto @paulrobertlloyd With the increasing complexity of the other PR, I'm wondering whether we should opt for this approach instead?

I've just added 2px adding and swapped the margin right (which wasn't working) with flex gap.

I think it looks OK like this but we'll need to look at the responsive logic as the items don't collapse into the menu correctly now. (the live version is a bit janky on this too).

[anandamaryon1]

Made a small tweak, to reduce the padding on the menu button chevron so that it fits better with the other items, saves 7px too:

Before	After

[paulrobertlloyd]

If we’re happy with this PR, can we squash it before merging?

[anandamaryon1]

@paulrobertlloyd not something I've done before, does it combine all the commits into one for the history? Feel free to squash away 🍋

[paulrobertlloyd]

Exactly that. By having one commit (especially in this use case) it's easier to track changes that were actually needed, not earlier experiments. It’s an option available on the dropdown for ‘Merge pull request’.

(I tried to rebase this branch last night, and gave up cos’ of all the previous merge commits… was half tempted to create a new PR with the final changes)

[frankieroberto]

🙌

@paulrobertlloyd I tend to think it's easier to allow loads of commits in a branch connected with a PR, but then use the squash-merge button at the end. But depends partly on how big the PR is.