SOLVED Weird mobile menu breakpoint behaviour
-
-
- Arnaud
- Sr. Rocketeer
- Posts: 233
- Thanks: 3
-
Hi there,
I have some weird problem with the switch between regular menu (for desktop) and mobile menu (tablets + mobile).
The breakpoint size is 48rem, which is the default value if I remember well.
Then I have some media queries in my CSS for 51rem and then 48rem (among many others of course).
But I get some weird behaviour on a very small zone (about only a few pixels width) around 48rem.
I mean the CSS changes are not clearly based on 51rem or 48rem.
Like the regular menu doesn't disappear exactly at the same time as the mobile menu appears.
And many elements in my page are just broken as well at this page width.
This zone is so small that I thought I could get away with it.
But as I could test it on some iPads a few days ago, it seems to be exactly this zone displayed on some models ! Bad Luck !
So I really do have to fix this issue.
The problem remains the same on any browser, any platform (at least it's stable… hmmm).
Any idea why this breakpoint zone seems to be a little "hazy" ?
Thank you !
-
-
-
- MrT
- Preeminent Rocketeer
- Posts: 101084
- Thanks: 13484
- Web Designer/Developer
-
I'm not sure why you are using media queries with those odd values? You media queries should all be using the mixin values (which are derived from the settings for the responsive breakpoints in the base outline > style (bottom of page).
// Gantry 5 custom CSS file // import breakpoints @import "dependencies"; // Typical values are the default breakpoints set in Gantry 5 // but these values are user definable in style settings // so that is why the code below uses mixins to get the actual // values from Gantry 5 template. // commonly used media queries // typically min 75rem @include breakpoint(large-desktop-range) { } // typically range 60rem to 74.938rem @include breakpoint(desktop-range) { } // typically 48rem to 59.938rem @include breakpoint(tablet-range) { } // typically 30rem to 47.938rem @include breakpoint(large-mobile-range) { } // typically max 30rem @include breakpoint(small-mobile-range) { } // Less commonly used media queries // typically min 60rem @include breakpoint(desktop-only) { } // typically min 48rem @include breakpoint(no-mobile) { } // typically max 47.938 rem @include breakpoint(mobile-only) { } // typically max 59.938rem @include breakpoint(no-desktop) { } // Mobile Menu Breakpoint @media only all and (max-width: $breakpoints-mobile-menu-breakpoint) { } @import "nucleus/mixins/breakpoints";
Check that your settings are correctly defined in the base outline (and other outlines).
If you need more help, Please would you post your URL, superuser id and pswd in the secure tab of your post and i'll have a look for you.
Regards, Mark. - Please search forums before posting. Please make sure your post includes the version of the CMS you are using and a link to the problem. Annotations on screenshots can also be helpful to explain problems/goals. Please use the "secure" tab for confidential information.
-
-
-
- Arnaud
- Sr. Rocketeer
- Posts: 233
- Thanks: 3
-
Thank you very much for your answer Mark.
I think you gave me a great hint to fix this issue.
I didn't know about this way to call media queries.
So I guess what happened to me is a weird mix between :
- Standard/default version using
// typically 30rem to 47.938rem
@include breakpoint(large-mobile-range) {}
- And my own CSS media queries :
@media (max-width: 48rem) {}
And I probably fell into the gap going from 47.938rem and 48rem.
Tricky !
Well, unfortunately, I had to create many different CSS media queries to finetune the display of several elements in my pages. I'll try to see if I can get a smarter solution with that…
So what I'm heading to now is :
- create a custom SCSS file for the default sizes you gave me.
- leave the "odd customized" media queries in my css file.
Does this seem correct to you ?
Arnaud
-
-
-
- MrT
- Preeminent Rocketeer
- Posts: 101084
- Thanks: 13484
- Web Designer/Developer
-
No. You should only use the media queries that I gave you and the code you just quoted Is wrong. Each media query has an opening brace { and a closing one }. You put your code that you wish to apply to that media query between the braces (not after it as you just said).
Regards, Mark. - Please search forums before posting. Please make sure your post includes the version of the CMS you are using and a link to the problem. Annotations on screenshots can also be helpful to explain problems/goals. Please use the "secure" tab for confidential information.
-
-
-
- Arnaud
- Sr. Rocketeer
- Posts: 233
- Thanks: 3
-
Mhhh… Maybe we only have a little misunderstanding here ?
I can write it this way if you like :
// typically 30rem to 47.938rem
@include breakpoint(large-mobile-range) {
.g-block {
display: none !important;
}
}
Right ?
I only deleted spaces for this quote, thats' it.
What I meant was creating an override customized SCSS file cause I don't think I can use the above instructions in a regular CSS file.
Then, because I still need some intermediate steps, I might still use the "odd ones" which are already in my CSS file.
Why do you think it might be a problem ?
I would be happy to have a shorter CSS file but the result wouldn't be correct in my case.
Maybe that's because I customized too many elements in the original template…
-
-
-
- MrT
- Preeminent Rocketeer
- Posts: 101084
- Thanks: 13484
- Web Designer/Developer
-
That media query is correct yes - albeit a very drastic thing to be doing in a media query (removing all block content?).
You should not need any intermediate steps to the main media queries.
Why can't you use those? Any custom CSS in Gantry 5 should be in a custom.scss file - that will be compiled. You can use regular CSS inside a SCSS file so there is no need to actually learn SASS. If you are trying to use custom CSS from another template then you will need to change the media queries to those used in Gantry 5 - you should not be using fixed values or intermediate values.
Regards, Mark. - Please search forums before posting. Please make sure your post includes the version of the CMS you are using and a link to the problem. Annotations on screenshots can also be helpful to explain problems/goals. Please use the "secure" tab for confidential information.
-
-
-
- Arnaud
- Sr. Rocketeer
- Posts: 233
- Thanks: 3
-
Oh, don't worry, I only wrote some random example that can be at least gramatically right, so that you don't get too upset. But it seems I failed again
Well, so far (for a few months now…), I've been using some customized css file (SCSS only when really needed) and it seems to be working and integrated with the rest.
OK, I'll try to see what I can do now and get back to this post asap, to share what I've been through.
Thank you again, you really helped me !
-
-
-
- MrT
- Preeminent Rocketeer
- Posts: 101084
- Thanks: 13484
- Web Designer/Developer
-
Ok I'll mark it solved for now then. Just reply here if you still need assistance.
You're very welcome.
Regards, Mark. - Please search forums before posting. Please make sure your post includes the version of the CMS you are using and a link to the problem. Annotations on screenshots can also be helpful to explain problems/goals. Please use the "secure" tab for confidential information.
-
-
-
- Arnaud
- Sr. Rocketeer
- Posts: 233
- Thanks: 3
-
OK, here is my feedback.
First, I tried to do what I said : set the standard media queries as you mentionned them, in a different customized SCSS file.
And then still kept my "odd" media queries in my customized CSS file.
But I realized this couldn't work, cause the standard media queries are describing a wide range of different widths.
Which is not compatible with all my "exceptions" described in the CSS file. Because those exceptions are "contained" in the wide range standard definitions (Am I clear at least ?)
So what I finally did was just the simpliest thing to do :
In my custom CSS file, the one I have been working on since the beginning, I just replaced :
@media (max-width: 48rem) {
// harmless css not to offend Mr. T
}
with
@media (max-width: 47.938rem) {
// same harmless css Mr. T can't disagree with
}
So that MY odd css media queries can still be functional.
What I didn't know is that when you specify 48rem in your Gantry template, it actually means 47.938rem…
The result is just perfect… in Firefox, Opera and Chrome.
But it gets even worse in Safari (OSX desktop version).
I still get some small "dark zone" where the "short mobile menu bar" gets broken and I can't even make the sliding mobile menu appear properly.
Which really bothers me, cause iPads also use Safari, even tho in iOS version (not sure how it would behave since I don't have any iPad to check).
After some further explorations (including screen captures and rem to pixels conversions) I think I have a clue.
It seems that Firefox, Chrome and Opera include the scrolling bars (15px) in the way they see the page width.
Which goes like this : 752px + 15px = 767px ---> triggers the breakpoint
But Safari triggers the breakpoint when the page content has a width of 767px.
Between 752 and 767, it's a mess, really.
Since I think Safari makes the scroll bars invisible on iPads, I guess it would behave properly (still have to check…).
But still… I'd be happy to get a clean result everywhere.
I'm sorry this is getting a little technical, but at least this issue is a little clearer to me than what it was this morning.
That's a start
Any idea about how I can handle this ?
-
-
-
- MrT
- Preeminent Rocketeer
- Posts: 101084
- Thanks: 13484
- Web Designer/Developer
-
As I said before, you should stick with the media queries that I gave you. You cannot use your old media queries. You old media queries will not match what the template uses and that's why you will run into issues. You must convert any old code to use the proper media queries that I gave you.
Regards, Mark. - Please search forums before posting. Please make sure your post includes the version of the CMS you are using and a link to the problem. Annotations on screenshots can also be helpful to explain problems/goals. Please use the "secure" tab for confidential information.
-
Time to create page: 0.074 seconds