Varya: Add mobile navigation treatment

[kjellr]

This PR adds a small-screen menu treatment to match the design comps. Still a few things to do:

• Fix bug where the top of the screen is scrollable.
• Adjust the position of the menu if the WP-Admin bar is visible. (Currently it gets hidden behind the bar).
• Fix the horizontal scroll overflow.

... and probably some more bugs too!

---

Before:

After:

[kjellr]

This is ready for a review. The only major bug at this point is that it appears to be totally weird in Safari. 😄 I'm still looking into that, but if you happen to determine why please let me know.

[kjellr]

Some of these new variables feel bit granular, but I included them because I figure we'll want to override them pretty easily for child themes.

[allancole]

Yeah, at first I thought this might’ve been too complex, but its actually kind of necessary to easily make a ‘Vanilla’ version. 👍

[kjellr]

Just added a subtle animation too (slowed down for the GIF):

[jffng]

Mobile menu is looking nice! I encountered two bugs:

1. The desktop menu is inheriting a few mobile styles, so it's not appearing:
   

2. The content underneath the menu is still scrollable on mobile
   
   :

[kjellr]

The desktop menu is inheriting a few mobile styles, so it's not appearing:

Ah, that was working until my last animation commit. 😄 I can sort that out.

The content underneath the menu is still scrollable on mobile

This is a tougher one. I'm not totally sure I can restrict that without JS. Will take a closer look.

[kjellr]

The desktop menu is inheriting a few mobile styles, so it's not appearing:

This should be fixed in e0e7eb0.

The content underneath the menu is still scrollable on mobile

I did some further digging for this one, but I'm not sure we can implement without adding some (very simple) JavaScript. Right now, the menu is opened and closed via just some CSS and a checkbox. There is a CSS property that could do what we're looking for, but its browser support isn't great. As it stands now, we otherwise reach up the DOM tree to tell the rest of the page not to move when the menu is open.

A potential fix would be to allow the background scroll, but hide it completely behind the menu (this is what happens on logged out views already). This would at least remove the distraction of the scrolling content. But when you close the menu, you'd be in a new spot on the page, which is disorienting. In addition, this would require placing our theme's menu above the WP-Admin menu, which seems hacky, and also requires the Menu button to move when the menu is open:

Given all that, I think the simplest approach would be to just add a quick couple lines of JavaScript to handle this for us. The theme is mostly devoid of JavaScript at this moment, but it seems like this is a good use case for it.

Would it make sense to handle that in a separate PR? (and either way, would you mind doing another review of the code here?)

[jffng]

I made a handful of changes that address the desktop menu positioning.

Here's what I was seeing before:

And after:

[kjellr]

Thanks @jffng! Seeing the menu up there, I'm having second thoughts about its position. I think rather than keep the menu up there (as in the original comps), it would be simpler to put it back down underneath the site branding. This will remove a bit of the awkward hierarchy that's present when the menu is up top, but the branding is below it.

I imagine that might be a better starting point for child themes too. I'll add a couple commits to take care of that.

[nielslange]

Based on https://uxplanet.org/the-ultimate-guide-to-the-hamburger-menu-and-its-alternatives-e2da8dc7f1db (and other similar sites), I was wondering if it wouldn't make more sense to have the mobile navigation at the bottom of the screen, thus, where it's much easier to reach? (Please ignore my comment if you believe that the hamburger menu is the way to proceed here.)

[kjellr]

I was wondering if it wouldn't make more sense to have the mobile navigation at the bottom of the screen, thus, where it's much easier to reach?

For apps, yes. But in the case of the mobile web, some web browsers (Safari 👀) have UI that actually makes bottom-aligned buttons a bit more difficult to use. Here's an example showing that opening a bottom on Safari menu frustratingly takes two taps instead of one:

[kjellr]

I got some fixes queued up for this, but it turns out they also break the mobile menu. I'm starting to think I should take a step back and spin this all up in a fresh PR — one with a little snippet of JS from the start, with a cleaner approach.

[allancole]

Looks great! All this needs is support for the Woo cart.

Desktop	Mobile

[allancole]

Yeah, at first I thought this might’ve been too complex, but its actually kind of necessary to easily make a ‘Vanilla’ version. 👍

[allancole]

I wonder if this can be connected to a nav-line-height or nav-font-size variable, so the icon size can be relative as opposed to an absolute pixel value—if thats even possible.

[allancole]

Given all that, I think the simplest approach would be to just add a quick couple lines of JavaScript to handle this for us. The theme is mostly devoid of JavaScript at this moment, but it seems like this is a good use case for it.

Agreed 👍

Would it make sense to handle that in a separate PR?

Seems like the JS would be simple enough to do it on this PR 👍

[kjellr]

Closing in favor of #56.