Global Header: Add in styles to fix older browsers.

[StevenDufresne]

This PR copies in Gutenberg Navigation styles that include the :where CSS declaration which causes unusable layouts in older browsers.

Fixes #159

Why does Gutenberg use :where?

Gutenberg uses these conditional css selectors because the Navigation component has a "Open on click" feature:

When that feature is toggled on, the hover functionality is not added to the submenus.

What are the risks?

There isn't much risk since the CSS is implemented behind the supports declaration, however:

• Should we ever turn on "Open on Click" for the menu, these changes will not work for that.
• We carry forward some technical CSS debt in an "active" CSS file.

Screenshots

Environment: Windows 8.1 - Chrome 69

Before	After

Incidental Changes

• In order to use @supports, we need to update postcss-preset-env. The current version is using an older autoprefixr version that does not support @supports.

How I tested this fix

• Build global-header component
• Copy style.css from build folder
• Loaded Windows 8.1, Chrome 69 via Browserstack
• Replace global-header-footer style.css source via chrome inspector tools with copied source.

I also did the same thing using the Falkon browser in a virtual machine.

[ryelle]

Visually this looks good (tested on Chrome 87), but the dropdowns can't be accessed by keyboard anymore. I think you can use :focus-within on the same element as :hover, but maybe double check the browser support.

[StevenDufresne]

Visually this looks good (tested on Chrome 87), but the dropdowns can't be accessed by keyboard anymore. I think you can use :focus-within on the same element as :hover, but maybe double check the browser support.

Thanks for catching that! I'll take a look.

[StevenDufresne]

Ok, using focus-within seems to work with chrome. 👍

I tested all the way back to Chrome 68. However, Falkon in my Virtual Machine won't tab into the navigation at all, which is a bit bizarre. It should work... 🤔

If we are okay with these changes, we could merge this PR, and reopen a new ticket with a smaller scope if that is still in fact a problem. It will give people a better ability to test these changes with little risk.

[ryelle]

Working with keyboard nav & screen reader (VO).

I left one comment that would be an improvement, but it's not a blocker since that's also how it works on production.

[ryelle]

Is this rule necessary? Technically it removes the element from the accessibility tree, so it no longer shows up in VoiceOver's links menu. The links are still accessible on the page, it's just the menu in the rotor that's missing it.

[StevenDufresne]

@ryelle Since #159 doesn't support selector support checks, any reservations just including the CSS for all browsers? I can't think of a good way to target CSS 4 selectors.

[ryelle]

any reservations just including the CSS for all browsers?

The risks you identified would now apply to all browsers, rather than just the older ones. We'll need to maintain the CSS, so if the nav block markup changes, our CSS won't know about that. Honestly that's probably true for other things on the site too, so it's not a blocker.