Responsive styles for secondary navigation component

[paulrobertlloyd]

Fixes #270, and builds on #273.

@benfraserdesign correctly reported that the responsive styles for the secondary navigation component could be improved. His PR in #273 goes someway to addressing the responsiveness, but by using table display, the navigation breaks if there are too many items and/or their labels are long.

This PR builds on this work, using the design of equally spaced navigation items with centred text labels between mobile and tablet breakpoints. Below the mobile breakpoint, and above the tablet breakpoint, the navigation more closely follows the design of the service navigation component, which wasn’t a thing when this component (or the components that inspired it) was first designed. SCSS from the service navigation component is liberally applied here.

< Mobile

	Screenshot
Before
After

Mobile > Tablet

	Screenshot
Before
After

> Tablet

	Screenshot
Before
After

[frankieroberto]

@paulrobertlloyd @benfraserdesign hmm interesting! I’m not sure I totally buy the need to switch to stacked secondary navigation items on mobile, rather than keeping it horizontal (with wrapping). Stacking them takes up way more vertical space, and if you’ve only got a few short items, or quite a big mobile phone, then they might well have fitted on a single line anyway?

That said, currently it seems to switch to the Tablet layout from 321px and above - is that intentional? I had thought that 'mobile' was defined as being anything up to 640px width, with 641px to 768px being tablet and 769px+ being desktop?

Also not convinced by centre-aligning the items in the tablet layout, as then the text of the first item doesn’t left-align with the rest of the page, and also the extra padding in the items looks like it ought to be clickable but isn’t (although this could be fixed by making the full width and height of the item clickable).

Is it worth exploring keeping the tablet layout as is, but putting a bit more margin to the right of all the items (except the last one) to space them out a bit more?

Happy to be persuaded on any of the above points though, especially if there’s research or evidence from services using this pattern (which I’m not any more)!

[paulrobertlloyd]

Having items appear stacked on mobile:

• alleviates wrapping issues when a navigation list has many items
• makes it clearer which is the currently selected item (currently the blue border floats between rows; in the example above is Overview or Settings the current item?)
• is consistent with the presentation in the service navigation component (though granted, this is hidden behind a ‘Menu’ button)

As to the tablet layout, agree it is perhaps odd to have three different layouts, nice as the tablet variant is. Perhaps increasing the space between items above the tablet breakpoint would achieve a similar result?

@benfraserdesign’s original design did have the entire item be clickable, as does the current version in fact. I removed this again to be consistent with the service navigation component… which isn’t necessarily right, of course. Maybe something to ask the team behind the service navigation component, perhaps they had a good reason for not doing this?

[paulrobertlloyd]

That said, currently it seems to switch to the Tablet layout from 321px and above - is that intentional?

Have updated the PR message to correctly label the examples (hopefully).

[benfraserdesign]

Taking a look at the latest changes, my input would be either:

1
• keep the tablet styles but make the a tag fill the entire li: means users get a big-as-possible clickable area
• mobile stacked design works nicely: again, we could make the a fill the entire li for max clickable area

or

2
• remove the tablets styles all together
• remove the need for using flexbox and the associated (minor) browser compatibility issues and code complexity (ie. leave original styles tablet upwards, and for mobile remove the float and display block).