fix: switches secondary nav max-height from 'auto' to 'none' at deskt…

[ctorgalson]

Re: #807

...op sizes

"auto" is not a possible value, so it fails to unset the max-height value set for mobile/tablet sizes, sometimes obscuring menu items.

To reproduce

This is relatively difficult to trigger on the LGD demo because the menu only has three items. The following steps make it seem absurd, but with menus containing 20+ items, it's easier to trigger :)

1. load a page like e.g. https://demo.localgovdrupal.org/localgov-drupal-demo
2. in the browser's css rules panel, find the selector .region-secondary-menu .menu-item > a
3. to that selector, add font-size: 5em;

The result is like this:

What does this change?

The new code uses a valid keyword for max-height in secondary-nav.css.

How to test

Test as per "To reproduce" above

How can we measure success?

If the new desktop max-height value is honoured by browsers.

Have we considered potential risks?

This comes with very few risks:

• in most cases, it will be undetectable
• in some cases (like the one that prompted this issue), it will fix a problem
• in a very few cases, where a child theme's css is unintentionally (i.e. due to this bug) relying on the mobile styles' max-height value at desktop sizes, along with something like oveflow-y: scroll;, this could cause menu items to exceed the bounds of the menu container; this would be correctable with a single css rule

Images

Accessibility

• Tested with screen reader
• Navigable with keyboard
• Colour contrast passed
• The change doesn't use only colour to convey meaning

[finnlewis]

Looks good to me!