[Resolved] Bug at 1024 pixel

[Garth Dryland]

Hey Tom

It looks like I found another issue. Not sure how I missed this or whether you already know about it but maybe not so have a look at these images.

This issue is occurring on my blog. My blogs using masonry. Not sure if other options trigger the problem or not. My blog has configuration with large post top and medium posts under that. There is an image reflecting that here. At 1024px the right hand content is sitting down the left hand side.

This is occurring on the version you sent me. Have you seen this. Can or recreate it ?

Cheers

[Tom]

Can you try adjusting your container width to a couple different values and see if it still happens?

I know this can happen in some cases as masonry tries to calculate the correct widths based on the container width.

The logic definitely needs to be tweaked a little.

[Garth Dryland]

Hi Tom

One pixel either side of 1024 and the site displays as it should. This appears to only happen at 125% zoom on chrome. I haven’t tested other browsers.

I also just noticed that at 175% up to 500% (possibly more) the site displays as mobile view ??

Here are some screenshots

Cheers

[Garth Dryland]

Tom

I’ve been doing a bit more testing with both variations of v1.3.34 and depending on which one I use, they both appear to affect how my css positions content indicating the grid must be moving.

I’ve swapped back to the community version because the footer issues are actually worse than the 1025 pixel issue.

I have provided a couple more screenshots. These are using the community v1.3.34. The other version appear to act similar whereby the grid is moving horizontally whereas all the other issues the grid was moving vertically as far as I can recall.

Depending on the version (in this case the community version) the lower two widgets moving up about 12px (which is the padding setting) whereas the other version the top two widgets move up approx 12px (also the padding setting).

Again this is at 125% browser zoom and if I go to 100% is seems to be okay on the community version anyway.

Hopefully this is of some help.

[Tom]

I also just noticed that at 175% up to 500% (possibly more) the site displays as mobile view ??

This is just how media queries work with browser zooming – completely normal. The good thing is, no one ever has any reason to zoom in 500%.

[Garth Dryland]

Hey Tom

This morning I tried doing this again and for some reason its only seems to happen from 250% to 500% now. Not sure why it changed from 175% as the start point.

I also tried on my production site which doesn’t have @media queries and it also does it.

I assume you’re referring to internally coded media queries in the theme itself such as at 769px that triggers the mobile menu which you put into the theme ??

Cheers

[Tom]

All GP sites have @media queries, and they will do some weird things when zooming in 500%. Not sure there’s a practical reason to ever zoom that much?

[Garth Dryland]

No reason Tom other than checking what the grid/site is doing.

I would like to think things should remain constant content position wise. The more I look around there seems to be a number of places the format goes out especially when it come to the blog and I’m talking at 110% 125% 150% zoom.

I haven’t recorded the exact positions pixel wise given I’m hoping that they’ll all be resolved when you sort the issues however there are quite a few positions where the right hand blog column drop down under the left side as an example. Footer widget also move around vertically and horizontally depending on zoom and site width.

Given I’ve added my own CSS / media queries (which I know aren’t causing these issues) I have been testing how my site looks and I know the grid has been causing me number of problems. I believe I have it acting how I want it to now but its only right (to the best of my knowledge) with browser zoom at 100%. Its certainly not extreme to zoom to 110% or 125% and both cause grid issue which makes content move out of position.

I only went up to 500% as a matter of interest to see what happens. In reality 150% is max practical zoom. There shouldn’t be anyone going above that unless they aren’t using any display zoom. A 125% display zoom in my view on an HD display with 125% browser zoom would be fairly normal, especially if the persons eyes aren’t perfect.

Hope that makes sense to you and clarifies my actions.

[Tom]

It does clarify it, but I’m still not sure I understand.. Content positioning etc.. will definitely adjust when zooming in and out, it’s the nature of zooming.

If you zoom in too far and the media queries think it’s hit 768px (zoomed), then the layout will change to the mobile layout. It’s the nature of media queries.

Here’s a video showing what I mean: http://screencast.com/t/l00xSnHTgh

Things adjust, but I’m not seeing any issues?

[Tom]

Here’s an explanation of the issue we were having in the first place: http://damienclarke.me/code/posts/those-1px-gaps-between-media-queries-can-be-a-problem

[Tom]

Here’s another example: http://screencast.com/t/ppkLZT4sFYT

When you get to the point where the content has no place to go and is going to cause horizontal scroll (bad), the media queries will kick in to prevent it.

This is expected behavior when it comes to media queries.

[Garth Dryland]

Hi Tom

Yes I understand the content will move using zoom though I would like to think the content should remain constant and in the same general layout, not randomly change at one pixel width, lets say 812px and at 813px be back to normal layout. These pixel figures are pulled out of thin air and only for the purposes of explaining what I see.

Firstly the issue I refer to generally affects the blog when using medium sized posts. Maybe small too though I haven’t tried that, whereas you used the forum which has full sized posts. At various levels of zoom the right side content drops below the left leaving the right side visibly without content. This also happens with a blog using a large first post and medium sized posts under that once the site transitions to a size whereby the large post becomes a medium post IE at 1024 pixels. You can refer to accountwise.co.nz to see this blog type configuration.

Secondly the issue footer wise probably wont happen on generatepress.com as you don’t appear to using media queries to position content moving it out of the default locations controlled by normal customise layout padding settings, whereas I am and I should be able too. I never saw this footer issue when using standard customise settings and no media query CSS. Having said that I also strongly believe its not my CSS or it would be a consistent issue and its not. When it comes to the blog I have also removed my CSS completely and the issue still occurs.

While I refer to zooming its also a combination of site width (pixels wise) and zoom at times and CSS which shows me the grid layout moves position at various levels of zoom when it comes to the footer. If you just zoom without being at an affected pixel width and you don’t use media queries controlling content position you wont see the issue. This is probably why you aren’t seeing what I see.

With a bit of luck I should be staging my site over to production in a day or two and then you may see what I mean if I provide the widths for you to check. I will post an update when its done to let you know.

I may even make a few Jing screencasts to help explain this. If I don’t stage my site for some reason I will certainly try to make some screencasts at some stage in the coming days to help clarify this.

Hope that helps

[Garth Dryland]

Hey Tom

These screencasts are using the community version 1.3.34 – The other version with 1025px fix gives different results. When watching these, use full screen or you wont see the pixels in bottom right corner and issues occurring up near the top of the page simultaneously.

For example the screencast on footer showing space below widgets, when using the other 1025px fixed version was actually losing pixels of padding above the widgets not gaining size below the widget like this version shows. I have come across other issues like this at various (pixel) widths/zoom but don’t see that recreating them will help at this stage.

In the remaining screencasts you will see various points where the right side blog column drops below the left.

I also read though the website you sent me above on @media queries and if I understand it correctly it implies chrome should not see part pixels which can throw format out plus some of these issues occur above 1025 pixels so should be outside of any such media queries anyway so don’t believe that info is entirely relevant to this issue.

Hope this helps you to understand what I’m referring to.

[Tom]

Hi Garth,

I appreciate the additional information – thank you!

Masonry definitely needs a little work in this regard – it’s obviously not handling the zooming well enough. I’ll see what I can do about that ASAP and will get back to you.

Thanks!

[Garth Dryland]

Tom

RE footer issue

For some reason I can set all my breakpoints max and min as the same figure respectively or with the 1px variation and everything seems to work exactly the same except for when it comes to the breakpoint that triggers the mobile menu. I assume this has something to do with it also being in the theme itself.

For example if I set “all other” @media breakpoints like this configuration

@media (min-width: 600px) and (max-width: 768px) {

@media (min-width: 768px) and (max-width: 1024px) { I get no problems. Everything work as if set like

@media (min-width: 601px) and (max-width: 768px) {

@media (min-width: 769px) and (max-width: 1024px) { except for when using these two specific variations.

For some reason no matter which I use I get a problem whereby CSS is not controlling position, but only in part. By that I mean no matter which layout I use I only loose part of the css. IE one (maybe two) side of four doesn’t work. In this instance, one way I loose 12px padding at the top of the element versus -50px off the margin at the bottom.

Why would this breakpoint act unlike all the others ?

Cheers

[Author]

Posts