Hello! I am having a curious issue with DevDmBootstra3’s breakpoints.
While the CSS DevDmBootStrap3 uses Bootstrap 3’s breakpoints, they seem to be off a bit when reacting to resizing the viewport.
For example, for the 1200px, 992px, and 768px breakpoints, the switch occurs at 5px greater than the defined screen width. The “large” breakpoint is at 1205px and greater screen widths, the “medium” is at 997px, etc.
I have not changed any of the breakpoints for the Media Queries.
What could be causing this?
I am using (and measuring screen widths within) Firefox 35.0.1.
any help anyone could provide would be greatly appreciated. Thank you very much!
That is some odd behavior Joseph and I have never experienced it. Even now toying with things I can’t seem to replicate the breakpoints not working right.
Is your project on the web somewhere so we can take a look?
My current project is temporarily located at http://portal2web.biz/webs/a4_sheltonreid . However, the same thing occurs at http://getbootstrap.com , so I doubt it’s my project that uses DevDmBootStrap3 as a WordPress theme which is causing the strangeness.
I am using Chris Pederick’s Web Developer toolbar addon with Resize->Display Window size in title set active, as well as two other “responsive design” helper addons, Firebreak (which displays viewport sizes in a button you can place in your menu) and Twitter BootStrap Helper (which displays which viewport size you are currently looking at, say, LG, MD, SM, XS).
The Bootstrap Helper triggers at the dimensions shown with the Firebreak tool as per my original post.
The Web Developer Toolbar reports the nominal “1200px” breakpoint (or “1205px” Firebreak point) as occurring at 1221px. I took a screenshot of my desktop (with the browser included) and measured the vertical scrollbar in Photoshop. It happens to measure 16px wide, so the Web Dev toolbar seems to be including it in its calculations, but the Firebreak addon doesn’t seem to include the scrollbar.
Then I thought of the All-in-One Sidebar addon I’m using too. In Photoshop it seems like it is 5px wide, and Firebreak is using it in its calculations for some reason.
It seems like for me to specify a custom MQ, I have to take Firebreak’s # and subtract 5px or WDT’s # and subtract 21px.
Just now it occurred to me that things like AiOS and the scrollbar might or might not be included in the Media queries in regards to how viewport width is calculated. I found this article that seems to hold this idea up-
So this issue is looking like it isn’t a Bootstrap issue (or a DevDmBootSrap3 issue) at all now. I am wondering, with the media queries as they are setup in BS3, what is the best way to account for the differences as highlighted in the URL I just mentioned.
I understand if this not something you’d want to worry about answering at this point since it looks like my post is diverging from a DevDmBootStrap3 issue, but I’d really appreciate reading your thoughts if you are amenable.
Thank you very much for your time!
I think looking at all these addons and tools you have going here is where you should start. While having all these things is great -they are supposed to save you time and energy. But they are not doing that right now. They are costing you instead of helping.
Sure, you could go one by one disabling them until you find who the culprit is and then contact the developer for a fix but I think you really just need to simplify your toolkit here. Do you really need hot swap buttons to go between the modes when FF and Chrome both provide mobile emulators in their inspector tools for you to test your code on the most popular devices? The native inspectors also populate the CSS inspector views with media queries when they are active. So I’m not sure how much any RWD addons are really helping you.
But I could just be a total ignorant boob here missing out on awesome stuff. 🙂
Good looking site by the way and all the media queries are functioning properly from what I can tell. It is always rewarding for me to see what people create using the Theme as a foundation.
I wish I had a solution for you but there are just way too many easily eliminated variables to track it down.
Firstly, I apologize for being forgetful here- I had wanted to say, thank you very much for providing the DevDmBootStrap3 theme. I think it is extremely helpful and useful. The project I provided a link to was my first try at making a RWD, let alone one that works with WordPress. That your theme allowed me the luxury of being able to do the work, is a real boon. So, I thank you and I appreciate your hard work and generosity!
The addons I mentioned do help me. I was just having some issues with whether or not they were reporting the proper viewport width or not (which I didn’t realize until I had activated both addons at the same time that there cold have been an issue here). I have used the RWD emulators in various browsers, but the main reason I don’t rely upon them is that I want to change the width of my browser manually to see how the screen elements change along the entire journey from approx. 1900px down to approx. 300px. Then I check out the “popular” viewports. Finally, despite their not being representative of anything other than themselves, I check what I can on my iPad2 and iPhone4.
But the main problem is not the addon tools I use, I discovered, but how the various browsers deal with the scrollbars or other chrome-like items that clutter the viewport as they affect (or are affected by) media queries.
Without using something like a CSS preprocessor, or JS, I don’t think there is a way to account for the discrepancies. I was hoping to know your thoughts on that issue, if you are amenable. Again, thank you for your time!
Thank you for the kind words. 🙂
I’ve not been impacted directly by this behavior but I’ll imagine myself in a position where the scroll bars were a problem.
If the scroll bars were really a major concern for me I would stick to some good ole JS to give my container elements the required negative padding to account for their width. I don’t really see any other solid way to go about it. I’m sure you have Googled this already and ran into threads like this on stackoverflow:
But that really feels like a perfectionist way to go about it and pretty self serving just so you can use your current work flow. MOST mobile browsers aren’t going to even have scroll bars and already overlay any scrolling indicator over the content. In the end you might be having some of your mobile users do some extra calculations for no reason taking a performance hit.
You must be logged in to reply to this topic.