Page exceeds viewport width in FF

Forum Moderators: not2easy

Message Too Old, No Replies

Page exceeds viewport width in FF

Horizontal scrollbar only in Fireforx

laurasamps

2:23 pm on May 26, 2011 (gmt 0)

Hey guys.

So here's my problem...in every browser, my site is good, except in Firefox where it is oversized. Its not a zoom problem, and I have been through this section on the forum and can't find a solution, can anyone help?

Thanks,

Laura

rocknbil

4:57 pm on May 26, 2011 (gmt 0)

Define oversized. Layout too big or just elements too big? (fonts, etc.)

Validated the output of course?

Got some **basic** CSS/HTML to share?

If it's the entire "page" going too big I'd say something is goofy with your FF install and it may be stuck in a zoom state.

laurasamps

8:41 am on May 27, 2011 (gmt 0)

Hi,

it's the entire page thats too big, and when I found it I thought it would just be the one computer too, but the same problem is on firefox on every computer I've been able to check....except mine! On Chrome, IE etc the page fits nicely into the screen, on firefox it has a scroll bar at the bottom and only about 3/4 is viewable within the screen. Hope that makes sense.

I've validated the output - no errors.

I've just included the very first part of code as the rest concerns text only and I'm assuming I've missed something out of this part rather than it being the text thats the problem, since everything is oversized.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Greenaway Amenity Limited - The Natural Choice In Weed Control</title>
<style type="text/css">
body,td,th {
font-family: Arial, Helvetica, sans-serif;
font-size: 14px;
color: #FFF;
}
body {
background-image: url(images/background.jpg);
}

Thank you!

alt131

10:39 am on May 27, 2011 (gmt 0)

Hi laurasamps,

it has a scroll bar at the bottom and only about 3/4 is viewable within the screen

That's the key piece of information for me, so hopefully we can get a solution without needing more code.

Browsers vary on their error handling, so good on you for validating - but in this case I suggest double-check the css and the html (especially the html) just to make sure ;)

Then look for elements that have a width/padding/margin combination that would make them wider than the viewport width. Also check for positioned elements that have been shifted from their actual position using a negative left or margin-left.

As you are using firefox, the firebug extension makes it really easy to check dimensions in the "layout tab". Otherwise set a border/background on each element so you can see where it is being drawn.

laurasamps

1:48 pm on May 27, 2011 (gmt 0)

the largest viewport width I have is 1250px, am I doing wrong for having this as big?

Within this largest table (please don't tell me off for tables!) there are some elements which are set to % widths - am I better off setting these to a specific px or will they be ok? I'm thinking these can't be the problem, since they are within a total boundary of 1250px?

I've just installed firebug on your advice, I've found the layout section you're referring to - it all looks to be ok - but I will research how it should look now since I've never seen it before.

Hope I'm being clear - thanks for your help :)

lucy24

8:55 pm on May 27, 2011 (gmt 0)

Is it the physical size or the pixel count that changes? If you're trying it on different computers-- which is a terrific idea precisely because it's showing you things that don't work as you'd hoped-- you may be looking at not just different fonts* but different dpi/ppi in the display. So you've got three different measurements: ems, physical size (inches or cm) and pixel count. Does any aspect of the page change if you change the monitor's resolution but nothing else?

I once spent an exhausting session trying to make my son understand that in modern monitors a pixel is not only a physical dot on the screen, it's also a unit of measurement. The first generation of Mac and Windows were 72 and 96dpi respectively. Those were easy to understand, because the same number meant both; they were actual points of light that you could see if you looked close enough. But now the measurement and the physical dot are separate and unrelated things.

:: shuffling papers ::

[lucysworlds.com...] (531byte gif image)

At the time I made this image (for use with e-texts using words like "actual size") in 2007, the ruler displayed at actual size on my monitor. Now, on a different computer, it's a bit smaller.

* That is, even if you say explicitly "14 point Palatino", different computers may render it differently depending on age of the monitor and source of the font.

tangor

9:25 pm on May 27, 2011 (gmt 0)

Curious... is there anything else before your </style> (which is not shown in sample code)? Not closing <style> can introduce problems as well... xhtml is a little more unforgiving, though some browsers will handle it internally...

laurasamps

9:30 am on May 31, 2011 (gmt 0)

tangor : there is some other css, but I have closed the <style> tag correctly.

Lucy : I'm looking into this now, like your son, these things don't come naturally to me so it takes me a while to work out, but if I see something odd I'll post it back.

Thanks for ideas guys.

alt131

7:57 pm on Jun 1, 2011 (gmt 0)

OK, after some off-forum discussion, the site is a table with a width set to 1250px. Where I am the display is uniform across all browser/version and despite changing monitor resolution - no obvious code issue. An interesting mystery!

Laura, some terminology - very general as you've said this is new - anyone else please feel free to provide a better explanation.

1. Page/Document width - that's the width you've specified in your code, which for this document is 1250px. Whether that's a good width depends on your target "user", and that is about their expected viewport size and monitor resolution.
2. Viewport width - the browser width, less the "chrome" (scrollbars etc). The width varies depending on monitor resolution, borwser scrollbars have different widths, etc. (But scrollbar widths won;t account for thr 25% difference here). The other challenge is the user: Grab your browser and reduce it's width by 1/2 the screen - you just 1/2'ved the viewport width - it's that simple ;).
3. Monitor resolution. That's the setting applied to monitor. If you're on windows, find it under Control Panel / Display / Settings. If you haven't thought about this yet, it makes a big difference. For example my eyes get tired so I'm on 1024px wide - a site with width=1250px has a scrollbar. If I change the setting to 1280px the scrollbar isn't required - as you would expect.

... no, it's not that simple :) - for example, all the issues Lucy referred to - but hopefully enough to start.

To summarise, this is a 1250px fixed-width page that is forcing a horizontal scrollbar in firefox on every screen except one.

To eliminate the first variable - is your montior resolution wider than the others? Second, can you just confirm this is definitely not happening in ie or chrome - but is doing it for a maximised firefox? And when you return, can you also provide the versions?

SuzyUK

9:22 pm on Jun 1, 2011 (gmt 0)

this may or may not be of help.. you cannot fix a table width any more than you can fix it's height, a table by it's very nature will stretch. It's what it does it's why everyone likes them, until they can't fix them! (fix as in restrict)

so thank you alt for clarifying the other widths/heights but they do not matter

my guess is that the screen that is not forcing the scrollbar is the one that actually really does fit into a 1250 layout

my advice is (and I've never been a table nay-sayer) is do not try to make it do magic, even tables can't fix everything, they haven't been able to do that for a very long time!

It's boring maths most of the time, and I don't want CSS to be able to do maths.. if I could see an example of this I would be willing to bet that a block formatting context might help (not necessarily Laura's son, but logically!)

alt131

1:43 am on Jun 2, 2011 (gmt 0)

Hi Suzy, So good to see you back. (For those unaware, Suze used to mod here; )

Thanks for that. Maybe poor choice of wording on my part: The table has internal elements such as images that are holding it this wide (or there-a-bouts) as well as the explicitly set width.

Second, this isn't a difference between monitors:

On all monitors (except one), there is no scrollbar in ie and chrome. While on the same monitor there is a scrollbar in firefox.

The only variation is that on one monitor there is no scrollbar in any of them. And yes, my guess is this will have a wider resolution - hence asking Laura to check so that variable can be eliminated..

I can't see anything in the code that would cause ff to interpret a full 25% wider than Chrome and ie, and although testing across a range of versions I can't reproduce any differences here: At all screen resolutions and across a range of browsers/versions the scrollbar (or not) is so close to being the same as not to matter. Recalling we're looking for a reason for a 25% difference in width so a few pix here and there isn't relevant.

BUT you know what it is like though nested tables in the early hours - so another pair of eyes is most welcome!

lucy24

5:10 am on Jun 2, 2011 (gmt 0)

Lemme get this straight. Is each individual image coming out 25% wider in actual pixel count? Does it behave the same if you substitute dummy images such as b/w boxes of the same size? In the real page, are there two different images-- the background and foreground-- in the same location?

If there's text running across the background image (if there isn't, throw something in for testing) is it the same size in FF as in other browsers, or does it too get bigger to match the image?

This is starting to sound yummy :)

alt131

5:59 am on Jun 2, 2011 (gmt 0)

Hi Luce, not sure where Laura has gone, but there is a background-image set on body. When I said there were images also "holding" the table open, they are hard-coded in with specified px widths, and a rough check of the maths is within the ball-park.

Recalling that where I am there is absolutely no difference in the display on ie/op/winsaf/ff - regardless of version, screen resolution, or viewport width. For sure, at some screen resolution or viewport widths there is/not a scrollbar, but that is consistent across all browsers at that particular resolution/viewport width. I can't reproduce any instance of ff calculating/drawing any elements "wider" at all.

I've also worked through and removed all child elements. The display remains consistent - at no stage did any firefox version differ from any other browser/version at any screen resolution/viewport width.

Of course, other thoughts are box model, different viewport heights and slightly different viewport width calculation that might trigger a scrollbar - but the difference here is much more than a few px.

lucy24

7:03 am on Jun 2, 2011 (gmt 0)

not sure where Laura has gone

To bed, probably, if she's posting from England.

I looked more closely at my own Firefox prefs and immediately came across the "add-ons". Is it possible that the troublemaker is not Firefox itself but some unsuspecting or unsuspected extra? I don't have any myself, but I assume there's some way to disable them and check for a change in behavior. Is everyone using the same version of Firefox? Or, at least, is one of the other computers using the same version as yours?

The CSS is indeed perfectly lovely and validates a treat... but have you taken a closer look at the html? Gazillions of errors and warnings, not all of them attributable to unclosed tags. Was it originally written in some other (X)HTML and then changed? XHTML tends to throw fits about things that are perfectly normal in HTML.

:: irritably wondering when the CSS validator decided to abandon yapping about "color" without "background-color" and vice versa, now that I've utterly internalized "background-color: inherit" just to make it happy ::

alt131

8:55 am on Jun 2, 2011 (gmt 0)

Lucy that would be a long sleep Laura's last post was 47.5 hours ago!

For anyone following, this isn't a secret club, I've stickied a link to code to those interested.

but have you taken a closer look at the html?

Yup - recalling the reason for looking at the code is try to find the source of the error and this is very good compared to what we frequently see here. There is an unclosed <p> and <a>, which the browsers are self-closing. The remainder are missing "alts", and deprecated properties/values that won't be having an effect. That leaves the entity references and given one of my tests was to remove all child elements (which also means all invalid code), they aren't having any effect either. So while validation is really important, in this case invalidities do not seem to be the problem.

However here's an interesting side-bar: The opening of the document is as Laura posted above. Yet the first (and sometimes second) validation using jigsaw at default settings validates as HTML 4.01 - not XHTMl. Hitting "revalidate" brings up validation as xhtml. Using Unicorn this validates as xhtml first off. Has anyone experienced jigsaw doing this before?

Clever thinking about add-ons. To keep narrowing this down - are you seeing Laura's reported layout variation between ff and others - or like me, not seeing that at all?

laurasamps

9:38 am on Jun 2, 2011 (gmt 0)

Hi! Sorry got a new mac, so I wasn't ignoring, just setting up :)

There's definatly a lot of stuff there for me to think about and try to work out.

For the first part;

To eliminate the first variable - is your montior resolution wider than the others? Second, can you just confirm this is definitely not happening in ie or chrome - but is doing it for a maximised firefox? And when you return, can you also provide the versions?

Like on my old laptop, on the new mac, I'm seeing everything fine in Firefox, IE, Chrome etc etc, but others are obviously still not. My current screen resolution is 1440 by 900 (taken from the apple website - I shamefully do not know how to see this of my own accord!)
I have tried 5 different laptops and computers that are available to me (including one identical to mine) and they all force a scroll bar and do not display the right hand side 25% in the viewport. Do you want to know their resolutions?

I can confirm its definitely not happening in ie or chrome.

The versions are all the most up to date versions, I checked they were all up to date.

I'm going back to re-read through these posts and see if I can work something out :)

THANKS EVERYONE! I really appreciate your time

SuzyUK

9:48 am on Jun 2, 2011 (gmt 0)

OK I received the link, thanks alt.. and am seeing no scrollbar in FF3.6.. is it fixed, is it FF4, or do we think this is a browser setting (or maybe to state the obvious, CTRL+0)

added: cross posted with you Laura.. not likely to be zoom setting on so many different test.. sorry about that ;) - So you are actually not seeing the scrollbar on all PC's/Laptops either? Is the version of FF showing the scroll different?
"Help > About Mozilla Firefox" in the top toolbar will get you the version

laurasamps

10:12 am on Jun 2, 2011 (gmt 0)

So you are actually not seeing the scrollbar on all PC's/Laptops either? Is the version of FF showing the scroll different?

No, I never get a scroll bar, ever, it's everyone else thats the problem! haha :)

"Help > About Mozilla Firefox" in the top toolbar will get you the version

Its firefox 4.0.1

SuzyUK

10:24 am on Jun 2, 2011 (gmt 0)

So FF4 is the one you can see the scrollbar in? or is it only on those other 5 pc's.. is their resolution less than 1280x768 (visit [whatismyscreenresolution.com...] )

try this link [markhorrell.com] to compare how site looks at different resolutions: in your case because the table is a fixed width it should show a scrollbar on a less than 1250 width screen

[edited by: alt131 at 10:48 am (utc) on Jun 2, 2011]
[edit reason] Tidy Link [/edit]

laurasamps

3:43 pm on Jun 2, 2011 (gmt 0)

my screen res is 1440 x 990

I'm just going to check the other computers resolution, and their version of firefox, as its them that have the problem. This is a good idea so hopefully will crack it.

However, I've just followed your second link, and no matter the resolution i try, the page remains within viewport for me, and does not force a scroll bar. in any browser.

But i'll double check anyway, thanks :D

lucy24

6:48 pm on Jun 2, 2011 (gmt 0)

In your System Preferences in the Hardware row there's one called Displays. It gives an option of showing an icon in your menu bar; it will look like a wee little black monitor in the cluster of icons along the top right. It's a good idea to enable this so you can easily test your pages in different sizes. On my OS the menu shows the most recent three resolutions I've used (yes, I sidetracked to experiment!), along with a link to the Prefs which gives you the whole list.

Wow, you've been working away at the page. All those validator errors I found last night have disappeared by magic. But yes, w3c really seems to have it in for your header ;) At one point it spurted something incomprehensible, so I pasted in my own xhtml boilerplate (note how the validator smugly says "In most cases, it is safer not to type or edit the DOCTYPE declaration at all, and preferable to let a tool include it, or copy and paste it from a trusted list of DTDs."). It is IDENTICAL to yours, but the validator shut up.

I thought I was just babbling but looking closer I'm guessing the doc really was in html originally, since so much of the validator fuss was about unclosed this and that.

The page looks identical on all five of my browsers omitting Lynx with one interesting exception that I can't pinpoint in the code. In Opera and Camino (! are you listening, �?) the 10px-border around the main image displays as "outset". In all others (Firefox and the Apple Web Kit-based browsers Safari and Chrome, as well as the text editor's html preview) it's transparent.

A lot of stuff can and should be moved from the html to css-- not because it will solve your problem but just because. I added this block:

img {border: none; text-decoration: none;}

div.center {text-align: center;}

table {font-family: inherit; font-size: inherit; width: 100%;
border-collapse: collapse; border: 1px solid white;}
table.main { width: 1250; border-width: 10; border-color: transparent;
text-align: center; margin-left: auto; margin-right: auto;
background-image: url("images/fade.png"); }
table.border {border: 2px solid white;}

td {padding: 0; border: 1px solid white; text-align: left;
vertical-align: center;}
table.seethrough td, td.seethrough {border-color: transparent;}
td.top {vertical-align: top;}
td.center {text-align: center;}
table.inner td {padding: 2px;}

It will take some fiddling to make the :: er, er, ahem, cough-cough :: three-deep-nested tables come out with the intended borders. The img stuff may seem redundant but it's the only way I've found to make it behave itself in all browsers when a picture is acting as a link. Which reminds me: be sure to get rid of any spaces within image names! (Different thread.)

I normally loathe inline CSS but I recommend using <style = "width: 350px"> etc on table cells if needed, because this method seems to be more, um, assertive than the straight html method. If the width of a cell is identical to the width of its content, you don't need to say anything about alignment.

Incidentally, I loved seeing the ".h4" and similar, because I've only recently had it beaten into my head not to use header levels for presentation. So I do a lot of (in my version) <h2 class = "six"> kinds of things :)

SuzyUK

10:34 pm on Jun 2, 2011 (gmt 0)

I've just followed your second link, and no matter the resolution i try, the page remains within viewport for me, and does not force a scroll bar. in any browser.

it shouldn't? (I saw the scroll bar when I expected to at anything less than a 1250 width res) - don't be tempted to maximise the popup window!

if you maximise, you will of course be seeing it at your resolution not the one you asked to see it at!

how'd it go with the FF3.6/4 comparison?

laurasamps

8:23 am on Jun 3, 2011 (gmt 0)

if you maximise, you will of course be seeing it at your resolution not the one you asked to see it at!

This may have been my error!

However, just checked oone of the computers that are having trouble - res = 1280x768 HMM! :-S

laurasamps

8:24 am on Jun 3, 2011 (gmt 0)

yes, I sidetracked to experiment!

Thanks Lucy - appreciate your time.

Going to implement the changes you have suggested now :)

lucy24

4:56 pm on Jun 4, 2011 (gmt 0)

Follow-up to something I noticed earlier:

The page looks identical on all five of my browsers with one interesting exception that I can't pinpoint in the code. In Opera and Camino the 10px-border around the main image displays as "outset". In all others (Firefox and the Apple Web Kit-based browsers Safari and Chrome, as well as the text editor's html preview) it's transparent.

My best guess is that the two off-base browsers reasoned in their browserine brains that she can't possibly have wanted a 10px-wide transparent border or she'd have asked for padding-- never mind that tables don't have padding-- so let's make something pretty and I'm sure she'll be happy with the result. Like earlier versions of MSIE defaulting to grey table borders unless you explicitly tell them to use black.

So it's another case of Never Take Anything For Granted, and make sure the CSS says explicitly {10px transparent} even if you've already said in three other places that you want transparent borders ;)

SuzyUK

12:04 am on Jun 5, 2011 (gmt 0)

@lucy24, not sure I follow - if you get the CSS specificity right you should only ever have to say it one place

even if you've already said in three other places that you want transparent borders

if that's the case, then that's very possibly two times too many! - perhaps you just asked for the transparent borders in the wrong place the first 2 times?

CSS really is that simple.

lucy24

4:11 am on Jun 5, 2011 (gmt 0)

CSS is simple, but browsers aren't. If you've never had a browser merrily disregard something that's supposed to be the default, you've been very very lucky ;) or just haven't tried enough browsers. It's not always MSIE, either.

The "outset" behavior was from an earlier version of Laura's code when the CSS didn't mention borders at all. The table in question says <border="10" bordercolor="transparent"> and officially there ain't no such property as "bordercolor" so the six browsers were free to do as they pleased. Either by pretending there is such a property, or by tossing in their own default. Technically I guess they were messing with the border-style, which isn't an HTML property at all.

Just went to look it up. If you don't say, borders are supposed to default to your regular text color. (Got that, MSIE 6? Not some shade of gray.) In this case it was set to white for "body", "th" and "td", so a clever browser will instantly spot the loophole. I can't find the rule for overall table borders-- as opposed to cell borders-- but surely it would default to "solid". No idea what "transparent outset" would mean.

alt131

8:53 am on Jun 5, 2011 (gmt 0)

If you've never had a browser merrily disregard something that's supposed to be the default, you've been very very lucky or just haven't tried enough browsers. It's not always MSIE, either.

that got my attention until I realised the "you" was generic - not "you" at SuzyUK specifically. Suzy, please don't ever get the urge to share the list of browsers/versions you've coded for - there's still a forum limit on post size ;)

This is slightly off what we think the original issue was, but I think still relevant points for later readers, and a lot of work has gone in as well.

so I pasted in my own xhtml boilerplate ... It is IDENTICAL to yours, but the validator shut up.

Yup, given my issue with the document being validated as html the first (and sometimes second) time, I wondered if there were some stray hidden characters in there. I didn't have time to check - but I suspect you "got it in one" by pasting in a replacement.

In terms of explicitly setting borders multiple times, to state the obvious, a border isn't inherited by default. However, tables are different, and there is also the frame attribute, so webkit's default stylesheet explicitly sets border-colour:gray and inherit for table elements and the ie6-9 default is "grey-ish" (the colour changed between versions) - so not just ie6. A quick test in Op11/winsafari5/ie8/FF4 produces this:

With border="1"
a default table/td border of outset/inset, at the default black/gray colours, except for winSafari and ie which are the browser default gray/grey-ish.
frame="border" (no colour)
as above, but with no border visible for td there is only a single border "box"
With border="1" + table {colour:red}
a default table/td border of outset/inset, colour=red, but in ff it is visually a dirty red/gray mix, winSafari and ie the browser default gray and grey-ish, and only Op is really red.
frame="border" + table {color:red}
as above

ie6&7 boringly draw the grey-ish table/td inset/outset regardless ;) Interestingly, because the outset/inset should default to border-colour (which was never specified), there is an argument OP is wrong, even thoguht it was the most consistent. BUT all obeyed simple border-style and colour via css rather than html attributes.

So I think the strongest message is that deprecated + invalid + non-specific are volatile - best use style rather than html attributes and especially when using tables for style.

lucy24

8:36 pm on Jun 5, 2011 (gmt 0)

colour=red, but in ff it is visually a dirty red/gray mix, winSafari and ie the browser default gray and grey-ish, and only Op is really red

Yes, when I do something that involves judgment calls on the browser's part such as "outset" or "ridge" borders, the exact color range varies. Somewhere in the middle must be the actual color specified, but the lighter and darker elements aren't identical. (Obvious analogy to border size, where thin is always < thick, but exact pixel measure is up to the browser unless you give a number.)

Hmm, I should take screen shots and then take a closer look in graphics program. This kind of thing is potentially useful to know.
</drift>