I am building a responsive page and the media queries are firing at the wrong width size. I am using Chrome.
@media screen and (max-width: 1200px) {
.logo-pic {
display: none;
}
}
For example, this rule works it just fires at wrong size. This rule fires at 1320px and not 1200px. I have the meta tag for html in place. It seems to be firing the media query 100 or so pixel wider than it normall should.
<meta name="viewport" content="width=device-width, initial-scale=1">
I checked the previous responsive site I made and those breakpoints are firing correctly. I've tested the browser on different websites and the media queries are fine as well.
I found a similiar question on stack overflow but it went unanswered.
Media Queries breakpoint at wrong value
Not sure what the problem is?
Setting a particular "width-range" isn't any different from the way media queries are created. The only difference is the addition of more media feature expressions (that is, the screen width sizes). Take a look: @media only screen and (min-width: 360px) and (max-width: 768px) { // do something in this width range. }
If you want to include both min and max width for responsiveness in the browser, then you can use the following: @media (min-width: 768px) and (max-width: 992px){...} @media (min-width: 480px) and (max-width: 767px) {...}
In my experience, 320px, 768px, and 1200px are the most commonly used; these three values should be sufficient for targeting smart phones, tablets/laptops, and desktops, respectively.
A common reason this happens is if you have zoomed the browser window to a size other than 100%. In your browser, select the drop-down menu 'View' and make sure it is set to 100%. If you are zoomed in or out, it will trigger media-queries inappropriately.
And don't worry about feeling embarrassed. It has probably happened, or will happen to everyone.. but only once.
In order to avoid this issue all together, you should considering defining your media queries using a relative units (em
or rem
rather than px
).
You can also enforce setting the browser zoom level to 100% on page load using javascript.
document.body.style.webkitTransform = 'scale(1)'; document.body.style.msTransform = 'scale(100)'; document.body.style.transform = 'scale(1)'; document.body.style.zoom = screen.logicalXDPI / screen.deviceXDPI;
Just a short addition, to prevent others from searching further even though the answer is given here.
My zoom was already set to 100%, and still the issue was there. If you experience the same, the answer is simple: set your zoom to 90% and back to 100%, et voila, breakpoints on the width you want 'm.
Another addition. After an hour of debugging I realized I had coded multiple media queries and because css files are executed from top to bottom, I was overriding previous media query logic. Ex:
@media (max-width: 700px) {
.some-class { background-color: red; }
};
// This will override the above styling (assuming max-width logic is true)
@media (max-width: 800px) {
.some-class { background-color: yellow; }
};
Do you have iframes (or modals or smaller windows) loading the same CSS sheet with your media query ? If it's the case, it's a cache problem, and you need to link the CSS file with a dumb param like :
<link href="myCss.css?iframe=1" />
In order to load the css file as a new file instead of taking the cached version ... I hope I'm clear :)
I also had some problems with media queries in Chrome.
As soon as I toggled device toolbar, the scaling was just wrong. The following
<meta name="viewport" content="width=device-width, initial-scale=1">
fixed this issue.
I experienced this issue recently and I worked out it was the scrollbar that was causing the issue. I found this answer relating to the problem:
https://css-tricks.com/forums/topic/best-media-query-excluding-scroll-solution/
There were 2 proposed solutions:
html {
overflow: hidden;
height: 100%;
}
body {
height: 100%;
overflow-y: scroll;
position: relative;
}
This answer is a little hacky as the article mentions as well and it leaves you with a permanent scrollbar even when all the content fits on the screen. Therefore, I'm not a big fan of it.
You could use a JS solution to sort this out as well. The article gives a git repo link that deals with the issue.
Lastly, which isn't mentioned in the article, you could add a couple more pixels to your media rule to accommodate the scrollbar if it doesn't have to be precisely accurate. If it does, then the JS solution is your best bet.
Take a look at your units: rem
, em
, px
.
I just had this issue and it was because my base font-size is 10px and I put max_width: 102.4rem
in the media query, but it is activating at around 1600px instead of expected 1024px.
It still activates at 1600px on mine with 102.4em
, but it works as expected when I use 1024px
.
Here is an article that talks about everything I am hinting at:
https://zellwk.com/blog/media-query-units/
I missed the top voted answer at first because I experienced the problem using rem
not px
. Clearly, the root of the problem appears to be the units though.
Adding my solution, as none of the answers solved my problem:
I had styled my scrollbar to have a width of 10px (thin
in firefox), and the window's computed width was not accounting for the added width of the scrollbar, hence my breakpoints were occurring 10px thinner than the specified @media
query.
To fix, I simply added 10px (the width of the scrollbar) to the query, turning:
@media (max-width: 600px)
into:
@media (max-width: 610px)
Happy coding!
I ended up on this thread after an hour of frustration, in the end I realised I'd accidentally used min-height instead of min-width:
@media screen and (min-height: $sm) { }
instead of...
@media screen and (min-width: $sm) { }
Just a reminder to quickly check it if you were having the same issue as me face palm, it's late.
The problem is that Chrome will always include the scrollbar (acting exactly as window.innerWidth
, in contrary to document.body.clientWidth
or jQuery's $(window).width()
).
You just have to build your mediaqueries not pixel perfect, but always keep it consistent with window.innerWidth
in javascript logic. Otherwise you're down to overflow hacks and you don't want to go down that rabbit hole.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With