Header component has visible unusable menu button when CSS fail to load.

[NickColley]

Not a big deal but might be nice to use the 'hidden' attribute, or a hardcoded 'display: none'.

Done when

• TBC
• "Details of breaking change" section below completed to help with writing release notes

Details of breaking change

• which users are affected: TBC
• the change that’s been made: TBC
• changes users will have to make: TBC
• impact of users not making those changes: TBC

[kr8n3r]

button is also visible if CSS succeeds and JS fails, reason being #999

this can be remedied with hidden and display: block | inline-block in CSS for all 4 scenarios

• if css fails, the button should’t be present
• if js fails and css succeeds, the button shouldn’t be present
• if js succeeds and css fails, the button shouldn’t be present
• if both succeed the button should be present

but it requires a move away from using the templates' js-enabled class and having a method for each component to register that it's JS enhanced, say .js-ready or similar.

I don't think attaching a button via js is an option, as it adds extra complexity around when to attach it (only when navigation is present)

[owenatgov]

I'm going to put together a slight alternative to @kr8n3r's comment above based on our current approach on the design system website which itself is based on the approach on gov.uk. In brief, it uses hidden by default on the menu button and the toggle-able navigation list to handle visibility and a match media enhancement to manage changes in screen size, all but removing reliance on CSS for the show/hide feature.

The element visibility to progressive enhancement would look like this:

• no JS: button not visible, navigation visible
• JS: button visible, navigation initially not visible but toggle-able, button not visible and menu visible on desktop