Responsive Side Toggle Menu Enhancements

[molendijk]

I hope that clears up any confusion.

I'm afraid I explained myself not well enough. So here's a link to a demo-page which might provide a better explanation/demonstration of what I'm trying to say.

[Beverleyh]

Ah, I see what you mean. When I used an example top offset of 5em earlier, and you replied;

I know, but it's a fixed value. Now when the navbar (containing large text) displays in smaller windows, it'll take more and more vertical space, and may end up being partially hidden by the menu or partially hiding the menu. Resolving this issue with the help of media queries would force us to use too much breakpoints.

I can see now where the confusion came from - but allow me to explain - too many breakpoints wouldn't necessarily be required if you employ other responsive CSS techniques.

I'll reiterate that 5em was just an example, but the unit of measure needn't be a fixed one - a relative value like vw or % could be used instead to make it work better with a fluidly sized header (like in your demo).

From your demo;

how could css alone allow us to always position the top position for the toggle button and the menu at the required vertical distance relative to the header image, which will vertically shrink or expand depending on the size of the window and whose height is not specified (view source)!?

The 'padding-bottom' method would be a good one to use when the header height needs to be fluidly scalable. I wrote about it before, here http://www.dynamicdrive.com/forums/e...-Retina-Images and http://www.dynamicdrive.com/forums/e...ponsive-Design

I looked at your JS demo and recreated the scalable top offset with pure CSS http://fofwebdesign.co.uk/template/_.../ddsidetoggle/ and only one media query to cap the fluidity at a max-width. It's pretty robust.

The only notable modification I made to the menu markup was to use an inner div and transfer the styles to it (background-color, right border, shadow, etc.)

And I like the 'push content' option so decided to keep that in.

[jdadwilson]

This is the behaviour that we should ideally avoid because it takes control away from the user. Manual contraction (the kind your menu currently has) is generally considered more user-friendly because the user stays in control - they can choose when and how they want to navigate - maybe comparing menu items from different sub-menus in order to decide on the most suitable destination.

Does not this logic totally contradict most of the menus presented on this site. All of the horizontal drop-down type menus only display one sub-menu (drop-down) at a time. 'Manual contraction' is certainly not an option with them. Even a goodly number of the vertical menus that have either a click or roll-over option to display a sub-menu don't have a manual contraction -- move to another menu item and the previous sub-menu goes away.

jdadwilson

[Beverleyh]

I will clarify - I wasn't referring to horizontal dropdown menus. I was referring to the behaviour of modern vertical accordion menus (that are designed with responsive considerations) because that's the type you are using. Old scripts on DD many exhibit different behaviour because navigation patterns have changed in the last few years since touch and mobile became mainstream.

[molendijk]

Ah, I see what you mean. [...] I looked at your JS demo and recreated the scalable top offset with pure CSS.

Hi Beverleyh, that's pretty impressive indeed.
Two questions though:
1. When you slowly decrease or increase the window width whilst the menu is open, the top of the menu may get out of place. But I don't think this will pose a problem when the page is used the 'normal' way.
2. The first div in the body section of my page has:

<div id="fixed_header" style="position: fixed; left:20px; top: 0; right: 20px; text-align: center; background: #dedede; z-index:1; ">

We can make the header image smaller by increasing the values for left and right, for instance: left: 100px; right: 100px. When we do that, the top position of the menu button, the menu itself and the text on the page will automatically adjust to the new situation.
I wonder what will happen on your demo page when we change the size of your header image. If we replace

.header img { display:block; margin:auto; max-width:100%; height:auto; width:auto\9 /* IE8 */ }

with something like

.header img { display:block; margin:auto; max-width:80%; height:auto; width:auto\9 /* IE8 */ }

your header image will shrink. Will the top position of the menu button, the menu itself and the text on the page automatically adjust to the new situation? My guess is 'no', since 350 / 1260 x 100 will not work properly any more. Am I right?

Btw, your page will look even nicer on iPad when you put

html,body{height: 100%; overflow: auto; margin: 0; -webkit-overflow-scrolling: touch;}

That will keep the header image completely stable when the page is scrolled (see my demo page).

[Beverleyh]

1. When you slowly decrease or increase the window width whilst the menu is open, the top of the menu may get out of place. But I don't think this will pose a problem when the page is used the 'normal' way.

No I don't think it will either. It's probably an issue with your screen needing to refresh and the JS needing to recalculate. It's unfortunate that the menu keeps closing during resize but hopefully you can fix it.

2nd point - Different use cases require different CSS. If you're familiar with responsive design techniques you'll recognise max-width:100%; height:auto; as basis responsive image CSS, so changing the max-width to anything other than 100% wouldn't be appropriate. To alter the size of the header/image in my demo, you would change the padding-bottom value instead. That's calculated by taking the width and dividing it by the height then multiply by 100. If you were working with a different sized image, you'd recalculate the new image proportions and transfer that to the CSS (in whichever places reference the image width or height) and this particular demo will just *work*.

Alternatively, if your asking about resizing the image within the banner (in effect creating a grey border round the edge of the image) I imagine you'd put a padding on the header div (the image container) and increase the padding-bottom offset to account for the change. Box-sizing may be required. I don't know - I haven't tried it.

3rd point - I don't think that's needed. It fixes the Safari browser toolbar to the top of the screen and stops the screen going full-size on scroll. If you want to restrict screen height by doing that, go for it, but it wouldn't personally be my goal.

That will keep the header image completely stable when the page is scrolled (see my demo page).

Sadly the header is nothing near stable in your example in Chrome, Opera Dolphin and Mercury. It isn't fixed during scroll and disappears off the top or bottom of the screen (depending on scroll direction). When scroll stops, it recalculates and snaps back to place.

[molendijk]

I don't know about Opera Dolphin and Mercury, but my header is stable with Asus Tablet DU9542 and iPad Air (and on desktop, of course).
As for my 3rd point, it solved certain ios resizing issues I had on iPad, see this.

[Beverleyh]

Feedback from Android - the JS demo constantly refreshes to give the effect of a persistent judder with the side menu flashing in to view every second or so. The top offset never gets chance to calculate so does not work. However, the CSS offset method works fine.

Having observed the behaviour of both demos on multiple/various devices and browsers, I feel that the CSS offset offers a more stable result and smoother, more consistent, visual effect in responsive environments. It's interesting to see both approaches though and I'm sure that users of the menu will find this thread useful in the future.

I'm closing the thread now to avoid it straying further from the original purpose of the thread. The OPs suggestions are on record and can be considered by DDadmin during future script modifications or rewrites.