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

[Under S.]

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!

[ALsp]

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:

<script>
function openNav() {
  document.getElementById("mySidebar").style.width = "250px";
document.getElementById("main").style.marginLeft = "250px";
}

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.

[Under S.]

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.

[BenPleysier]

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

[Under S.]

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?

[pziecina]

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.

[Under S.]

pziecina  wrote

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.

Is this true? So avoiding that line will only help on older phones, like my iPhone 5S?

Then the REAL solution would be to turn "initial-scale=1" back on for all pages (to keep with modern times) and take advantage of the fact that the site was built on "em" measurements to scale it DOWN to something that fits (via font-size: 0.75em, for example) when targeting cell phones only.

Otherwise, when I tried "initial-scale=1" in the past, it felt like the viewport on my phone was a little over 300px wide. Which doesn't line up with what http://screensiz.es/phone says is a 640px wide display for this phone. So I'm assuming there's a x2 multiplier in there because that's the only way those numbers make sense.

As a career designer, I can also visually tell that my iPhone's PPI is around 300 pixels per inch just by looking at it, so 300 pixels would only cover about an inch of width. Again, another clue that a multiplier is being used somewhere.

So am I to conclude that "initial-scale=1" makes the iPhone 5S (specifically) think it has half the pixels available that it actually does? How is that a good thing? Shouldn't borderless browsers be using 100% of those pixels and that PPI resolution?

Is there a viewport emulator out there for popular mobile device models? A website that will display yours in an iFrame custom-built to different phone specifications, for example.

[ALsp]

Just a quick interjection, here. Take it for what it's worth. In our experience, on a well-coded and scripted page, this viewport meta tag should be all that is ever needed:

<meta name="viewport" id="p7LBM" content="width=device-width">

Anything else will tend to alter default behavior in the device, which we usually try to steer clear from, for the sake of usability.

[Nancy OShea]

A pixel is not a pixel.

Using the viewport meta tag to control layout on mobile browsers | MDN

[pziecina]

You are going to have to learn a lot more about retina and hi-dpi screens, I think, but don't worry we are all still trying to come to terms with it.

What you must remember is that the multiplier, (as you call it) has so many different ppi's that to build a site for all of them would take months just for a very simple site, which is why the viewport meta tag, (and the css @viewport) is required. The multiplier can be anything between 1x and 5x, (with upto 8x on the way) so the viewport tag is simply a way for text to be displayed at the developers settings. Images however are displayed at the devices native ppi, so if you have a 3 inch wide image on your desktop with a standard hd screen, (96ppi) a phone with a ppi of 288ppi will only display as 1 inch wide, (1 image pixel = 1 device pixel). That is why srcset is required and the css image-set.

See -

https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images

and

https://responsiveimages.org

Video also has the same problem, but as many internet users do not have the speeds required for 4k video delivery, normal and hd are all that is currently required, with many just offering standard.

[Nancy OShea]

https://forums.adobe.com/people/Under+S.  wrote

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.

If the viewport meta tag causes your layout to blow-up, that tells me your  design approach is flawed in some way.  Please post a link to your work in progress.

[ALsp]

Ignore the Bootstrap. You have a learning opportunity here. Look very carefully at the CSS and you'll see a transition. The transition executes when the class is changed. Play with the CSS to do whatever you want to do. Experiment. It's a really, really easy technique to work, so don't ruin it with a bunch of bloated code - unless you are really into Bootstrap.

[osgood_]

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]

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]

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

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

[BenPleysier]

We are having fun aren't we.

From this I gather that you think that I am behind sending your reply to the Moderator queue. Fact is that I will tell you straight out even before I take such a measure. This whole thing is getting extremely childish.

Maybe this will help overcome this ridiculous situation, I am pulling out. I am a loser and you are the winner. May you all have a merry Christmas and a prosperous New Year.

[ALsp]

From this I gather that you think that I am behind sending your reply to the Moderator queue. Fact is that I will tell you straight out even before I take such a measure. This whole thing is getting extremely childish.

My reply was not sent to the message queue. It was flagged with a rejection notice. I obviously have no idea who did it, nor do I care, because it is very childish.

Maybe this will help overcome this ridiculous situation, I am pulling out. I am a loser and you are the winner. May you all have a merry Christmas and a prosperous New Year.

No matter how much I dislike Bootstrap and no matter how ridiculous this sparring is, I have no personal ill will towards you or Nancy. I'm not entirely sure the reverse is true, sadly. But if we don't get the opportunity to argue again, or if I'm banned from the forum, I sincerely wish you and yours  very happy Christmas and a joyous New Year. I really do.

[Under S. · Accepted solution]

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]

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.