Inspiring

Answered

Fixing this almost-perfect animated collapsible sidebar navigation menu by W3S

Forum|Forum|7 years ago
December 17, 2018
4 replies
1959 views

So there's this nice bit of code W3S recommends to create an animated collapsible sidebar navigation menu.

Its only design flaw appears to be that the main site content doesn't actually slide, it shrinks in width. In other words, content starts wrapping rather than sliding out of view.

Would it be possible to fix this without re-writing the whole thing? Just a small edit that will keep the (dynamic) width of #main intact while the left border slides over; possibly by compensating with a proportionate negative value on the right side?

Thanks!

This topic has been closed for replies.

Correct answer Under S.

I believe it was Nancy OShea who stated a few days ago that the best way to build this thing is to begin with the phone, and deprecate from there. It took me a while to understand why, but after resisting this whole time, I finally relented and stopped applying quick fixes everywhere. I slapped on "initial-scale=1" and started designing the phone view first.

Once I finally tamed this device, I realized how small everything was (in relation to itself) on a regular resolution/ppi monitor. But since I built everything on "em"s, upscaling at various resolutions was just as easy as I'd heard. In fact, there isn't a pixel measurement left on the stylesheet except for the initial default font size (16px, because I like to stick to default whenever I can and pick my battles on the customizing).

From there :

@media screen and (min-width: 50em) { body { font-size: 120% } } /* 50em = 800px */
@media screen and (min-width: 60em) { body { font-size: 140% } } /* 60em = 960px */
@media screen and (min-width: 80em) { body { font-size: 160% } } /* 80em = 1280px */
@media screen and (min-width: 120em) { body { font-size: 200% } } /* 120em = 1920px */

Once the foundation was well-secured, the above 4 lines are all I needed to do to handle every other size. The base code itself will collapse into single-column at 640px (40em) which will accompany every width < 640.

In other words, the code doesn't even need to target cell phones specifically to serve them the single-column layer. But it does, as a failsafe.

Y'all proud of me?

PS: I don't have any issues with Al, I appreciate pro AND anti opinions on various subjects; but I'd hate to see BenPleysier tap out. (Of all the superheroes in this forum, you've been the most helpful to me personally; I wouldn't be anywhere near this far along without your aid).

U

Under S.AuthorCorrect answer

Inspiring

I believe it was Nancy OShea who stated a few days ago that the best way to build this thing is to begin with the phone, and deprecate from there. It took me a while to understand why, but after resisting this whole time, I finally relented and stopped applying quick fixes everywhere. I slapped on "initial-scale=1" and started designing the phone view first.

Once I finally tamed this device, I realized how small everything was (in relation to itself) on a regular resolution/ppi monitor. But since I built everything on "em"s, upscaling at various resolutions was just as easy as I'd heard. In fact, there isn't a pixel measurement left on the stylesheet except for the initial default font size (16px, because I like to stick to default whenever I can and pick my battles on the customizing).

From there :

@media screen and (min-width: 50em) { body { font-size: 120% } } /* 50em = 800px */
@media screen and (min-width: 60em) { body { font-size: 140% } } /* 60em = 960px */
@media screen and (min-width: 80em) { body { font-size: 160% } } /* 80em = 1280px */
@media screen and (min-width: 120em) { body { font-size: 200% } } /* 120em = 1920px */

Once the foundation was well-secured, the above 4 lines are all I needed to do to handle every other size. The base code itself will collapse into single-column at 640px (40em) which will accompany every width < 640.

In other words, the code doesn't even need to target cell phones specifically to serve them the single-column layer. But it does, as a failsafe.

Y'all proud of me?

PS: I don't have any issues with Al, I appreciate pro AND anti opinions on various subjects; but I'd hate to see BenPleysier tap out. (Of all the superheroes in this forum, you've been the most helpful to me personally; I wouldn't be anywhere near this far along without your aid).

ALsp

Legend

No matter how much I may disagree with Ben, I neither dislike him nor would I want to see him tapped out. I've just made a reappearance on these forums but I go back to the beginning of Dreamweaver (I might be nearly as old as Ben, even ) There are many different opinions and mindsets in this field and debate is good sometimes. The key is to remain anchored to civility. But we're human and so sometimes there can be slips. The mark of a decent man or woman is in the recovery to a state of poise.

ALsp

Legend

I replied to this message with what should be considered a helpful bit of advice. My reply was even marked as helpful - I believe. The reply was rejected by a moderator hours after it was made. Since I am currently being harassed by at least 2 forum moderators, this seems kind of fishy. In any event, here is the original message. Let's see if it too gets "rejected". If it does, someone needs to man up or woman up and explain why.

BenPleysier

Community Expert

This is unreal. What on earth are you talking about?

Edit: OK, I now see what you are talking about.

Wappler is the DMXzone-made Dreamweaver replacement and includes the best of their powerful extensions, as well as much more!

O

osgood_

Legend

Add width: 100%; to the #main css selector:

#main {

width: 100%;

transition: margin-left .5s;

padding: 16px;

}

That should stop the container from collapsing and push it off to the right, hopefully!

You'll also probably want to add to the box-sizing css below to default the margin/padding to zero:

* {

box-sizing: border: box;

}

ALsp

Legend

It's kind of pointless. Simply slide the menu over the content. You might get other solutions, but personally I rather despise slide out navigation that displaces the adjacent content. So here is what I would do:

In the script:

function closeNav() {
document.getElementById("mySidebar").style.width = "0";
document.getElementById("main").style.marginLeft= "0";
}
</script>

Remove the second line (I bolded them) from each function.

U

Under S.Author

Inspiring

ALsp wrote
It's kind of pointless. Simply slide the menu over the content. You might get other solutions, but personally I rather despise slide out navigation that displaces the adjacent content. So here is what I would do:

Thanks, I appreciate it... but I'm aware of alternate overlay solutions, and would prefer pushing the main content off-canvas, unless there's reason to believe that won't work on today's browsers.

pziecina

Legend

BenPleysier wrote
Sort of like this https://www.jasny.net/bootstrap/examples/navmenu-push/?

I'm not anti-bootstrap, it just wasn't a thing when I stopped developing a few years ago (jQuery was still my go-to, although CSS now natively does when I would turn to jQuery for, which were esthetic enhancements like this one).

When I researched the subject of sliding sidenavs, I saw something similar to the script you just shared that ALSO required that the open/close button (hamburger icon) be on the left side of the website (close to the sidenav). Meanwhile, my original design has something else there (the site logo) and the 'open' icon on the right side of the page, even if the menu would slide in from left. So it would slide the 'open' button off-canvas on the right side of the screen, whereas the "close" button would be separate, and located in the sidenav itself.

That being said, both you and Al have me reconsidering a few things. First, whether or not I really want the site to slide like that since it causes problems on my phone that I haven't been able to solve yet (I've a feeling it won't struggle with an overlay as much). Second, whether or not I'd be open to switching sides and having the sidenav slide in from the same side the 'open' button is (ie, the right side).

At the root of the issue is the fact that this line everyone likes to use...

<meta name="viewport" content="width=device-width, initial-scale=1">

...zooms in on the design far too much on mobile, and breaks everything. As a stickler for consistency, I really, really wanted to use it... but the iPhone 5S and iPad 4 do not react well to it. And the documentation I've read on the subject suggests to drop "initial-scale" if the site design blows up when it's used.

Any more advice while I weigh the pros and cons of all this?

Just as a small snippet of info.

Removing the initial-scale = 1, or setting it to = 0, will not stop any iPhone/Pad zooming in anymore if the OS has been updated to iOS 9 or greater, as the setting now defaults to 1, and can only be changed in the user preferences, (in settings). The Android OS is also following in the iOS method.

The reasoning was that to stop a user zooming in, would be counter productive, especially for those requirering text/images etc to be larger that the site has set.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded