Webpage larger than screen, not sure why

Beginners
#3

Hi, RobM. Ya, I’m puzzled what is causing it, as I’m not adding any additional padding/margin, and I’d assume that even if the elements (images/text) within my Boostrap columns are responsible, they would be rearranged and shrunk as needed within each column. So, I’m really confused.

I’ll try making the container fluid, but I have to consider if that will affect any other aspect of it. The hidden overflow is a good idea, and I think that should be harmless, since nothing is currently getting clipped as it is (which further confuses me why the scroll bars are appearing… unless there’s some additional padding causing that, as there is visibly nothing that is actually pushing past the monitor screen borders.

I’ll have to look into it further, and will post again here if I have anything new to mention. Thanks!

UPDATE: One thing that MIGHT be causing it… maybe… is that I have a Position:Fixed ‘Back To Top’ button element which floats in the top left corner of the screen, independent of the rest of the page. Maybe that is pushing the container and/or body a bit? I’ll remove it, and see if the page size fixes itself.

It’s wierd… The section of the page that IS on the screen (when the horizontal scroll bar is positioned to the left) IS actually centered… so whatever ‘extra’ screen is causing the scroll bar to appear, it is ADDITIONAL to the intended size, and stuck on the RIGHT side of the page. If the browser DID show the whole (existing) page, the content would actually not be centered, but shifted over to the left. The extra screen space is something tacked onto the right side of the (proper) page.

Even the items (DIV background colours, etc) that span across the page stop where the extra screen area starts, leaving that whole vertical strip empty of any content… So, I guess the container is the right size, but the body has some extra space added to the right of it?.. like a right padding? (There’s no coding to cause that, but that appears to be what is happening…)

#4

Hrmmm… I looked into it a bit, and I’m still puzzled. I went through and hid each section (Row>Columns sections), until the scroll bar disappeared.

It seems that it is caused by things like (for example) my Bootstrap columns (even when completely empty of content) with a size of 8 and an offset of 2 in the MD size. This should be an exceptable setting (single column, not stretching all the way across the screen… the sum of the numbers not exceeding 12)… yet it appears to be (at least one of) the things causing the body to stretch an extra bit more to the right (…I verified that it is in fact the BODY that is being stretched to the right).

I tried the Fluid idea, but that didn’t appear to work/help. I have yet to try the hidden idea. I’m sure that will work, but I would preferably remove the unintended extension, if possible. But, it’s definitly going to be my final solution, if I can’t do that.

#5

That is a tough one to diagnose without seeing the code. A little like fixing a car over the phone.
I find that the developer’s tools window helps a lot in these cases. You scroll through the code, find the area that is overflowing and then check the margin, padding, display… for anything causing the overflow.
Good Luck!

1 Like
#6

Oh, for sure. I’m not expecting anyone to tell me why my particular code is doing this… just hoping for some info on what (in general) could cause this sort of thing, just in case it’s not something I have already considered.

The obvious things would be specific padding/margin tags on these items… but they all seem clear of these.

What is the developer’s tools window? I haven’t noticed that.

#7

From Pinegrow you right-click on the pinecone at the upper left. Then click on “Inspect”. The select element icon in the upper left can bring you to the area of the page where your code is being put together.
Most (all?) browsers also have development tools, it just depends on which one you are using how to bring them up.

1 Like
#8

Oh NEAT!! Well, that’s a fun littlle hidden thing!

Ya, you’re right… That reminds me of the browser inspect feature.

Actually, today I’ve been poking around Pinegrow (as well as searching for more vids), as I’ve always been suspicious that I have not been aware of some of the features/tools in there.

Okay, cool… another toy to play with. Thanks!

#9

Pinegrow is built on the Chromium engine, so it has many of the same tools as Chrome.

#10

UPDATE: For the sake of anyone following along, and curious about this, I did figure it out soon after my previous post. Turns out, I had one div or something outside of the container… kind of an easy mistake when you construct things via the heirarchy/stack panel (…the panel on the far right of the screen). A simple lack of enough indent, and you’ve got some overhang happening! Problem solved, though…

#11

i’ve come to just incorporate this rule in all my pages

html {
font-size: 62.5%;
overflow-y: scroll;
scroll-behavior: smooth;
}

the middle one keeps my page from jumping right and left as the scroll bars come and go (they just never go away now).

#12

I don’t understand why you’d want your font size to be reduced to 62.5% on all your pages?

1 Like
#13

it’s so i can use rem sizing that mirrors the px size

1.0rem = 10px
1.2rem = 12 px

and so on.

since i’m doing the “mobile first” approach, font size of 10px instead of 16px works a lot better.

#14

The other biggest advantage to the “62.5%” trick is that not only does it make using rems in units of 10 easier, BUT it ensures that if your user is visually impaired and they have their base browser font size set to something besides the usual 16px that your font sizes scale to what they prefer. This was used much more when browsers couldn’t scale font sizes set in px. Still seems reasonable to me, but with calc() and var() there are a lot of possibilities.

#15

10px seems absurdly small for a website. I’ve never used rems or ems, I’ve always used pixels.

#16

While I think 10px is a bit small, it is used in things like Google Calendar for the time/date labels. Resetting to 1rem = 10px is more about accommodating our brain’s love for units of 10 and divisibility by 2, not so much that we want to use a 10px font. Switching to em and rem give a lot more flexibility and design unity than using px, so not a bad way to go. One change at the base style can easily effect project-wide changes in font-size, and container size. Just my two cents.

#17

I understand how em and rem work. I’ve just never had an instance where in terms of design I found changing a base font size was adequate for a site-wide font size change. There would always be spots that the font size had to be tweaked. I prefer to use pixels and media queries to ensure the site delivers the exact UX I want and the screen size in question. I think ems and rems are holdovers from the days when browsers couldn’t scale the website.

#18

i originally had the site default at 14px instead of 16 and that still seemed too large on my cell ph, when i changed it to 10px it all looked more appropriate if on the small side. But not smaller than many of the system fonts on the phone…texting, etc.

there were several sites i visited which also had the smaller type, and it worked better at providing information without a lot fingering, even my email app uses type that is this size… and i’m glad bc i would rather not have ppl near me be able to read over my shoulder with ease.

many of the media sites use larger fonts… some of them so HUGE you could barely fit more that a few words across the screen

my understanding is the optimal width of a column, or mobile screen in landscape is ~7 to 10 words…mine’s at ~10.

perhaps it could be 12px and i may change it, but i’m still probably going to keep the base at 62.5% for convince

#19

Perhaps you’ve changed a zoom setting on your phone. 16px has always been the smallest I’ve ever gone on sites when I check them on my phone.

#20

the device zoom should be overridden with the

<meta name="viewport" content="width=device-width, initial-scale=1">

at the top of every page, so it renders true to the device screen size… now, devices are different so some will look better than others at any given font size.

i’m using an S4… not particularly ground breaking anymore when it comes to screen detail. my wife has a new iphone, so when i look on her device it does appear a bit small.

but this article was written about the desktop, so of course the font size needs to be bigger on monitor that’s feet away rather than a screen that is only inches away.

i might need to add another break point or two and when you get up to1500px like these big monitors now, i have to think about using that dead space on each side of the main content

there’s always more to do.

#21

This is interesting. Cheers all. and HI @Printninja :slight_smile: long time no see.
I checked out the site you posted, and in that, the author posted a link to the sites PREVIOUS layout on archive.org

https://web.archive.org/web/20130104231015/https://www.smashingmagazine.com/2011/10/07/16-pixels-body-copy-anything-less-costly-mistake

Now!
that’s where it got interesting, I was reading the comments, and they were all pretty much refuting the info -due to mobile/overall design considerations, especially the comment by Rob, here

https://web.archive.org/web/20130104231015/http://www.smashingmagazine.com/2011/10/07/16-pixels-body-copy-anything-less-costly-mistake/#comment-591002

So, that article made sense to me, as does @Printninja’s points, BUT…
I think I shall have to try the @droidgoo approach from now on when I get back into this.
And I too, never understood the 62% thng.
now I do, so cheers all, well explained. .

1 Like
#22

i think this is where i first got the idea from