Div width problem

[Ben502]

So i am trying to set a div to fill the entire width of the screen and it looks something like this:

#headercolor {
background-color: #FFB500;
margin: 0px;
padding: 0px;
width: 100%;
}

this is working great in all browsers EXCEPT IE9.

if you change the screen size with restore down so you could see other windows or whatever, it shrinks the backround of the div leaving the body background color exposed.

it does not do this in chrome, safari, firefox and so on...any thoughts?

[alt131]

Hi Ben502, recall that a div is a block element so will expand full width by default, but that width:100% is 100% of the parent element.
Does div#headercolor have a parent element that has a width<100%, or a padding or margin?

[Ben502]

the parent elements are the body and html tags. both st to 100% width 0 padding 0 margin.

it should be noted that a client sned me a screen shot of her computer doing it but i have not been able to replicate the problem.

[Ben502]

the closest thing i can get to replicating the problem is if i go into split screen mode in Dreamweaver. I have yet to be able to replicate it in any browser on multiple machines.

this is gonna make me start drinking.

[Ben502]

here is the CSS. Basically what it looks like is the body is working and taking its color all the way across the screen. However, if i shrink the screen (i can only make this happen in dreamweaver split screen and it is happening on my clients IE9) the container, header color and footer color all shrink. Any fixed width item such as my content areas are all fine.


html {
margin: 0px;
padding: 0px;
height: 100%;
width: 100%;
}
body {
font-family: "Trebuchet MS", Arial, Helvetica, sans-serif;
font-size: 14px;
margin: 0px;
background-image: url(../images/backgroundbluegradient.png);
background-repeat: repeat-x;
background-color: #00c6ff;
padding: 0px;
height: 100%;
width: 100%;
}

#container {
background-image: url(../images/stripesTrans40.png);
background-repeat: repeat;
min-height: 100%;
margin: 0px;
padding: 0px;
position: relative;
}

#headercolor {
background-color: #FFB500;
margin: 0px;
padding: 0px;
width: 100%;
}
#headercolor #header {
width: 960px;
margin-right: auto;
margin-left: auto;
}

[Ben502]

sorry for all the follow ups just trying to post what i am finding out in hops that it will enable someone to help me...so...

it looks like the body tag is squashing any of the other elements i have set to 100% as the window size changes.

for testing, i set the body tag to 2000px wide. at that point all of the "squashed" elements looked fine (container, header color, footercolor). This is leading me to think i got something screwy going on on the body, but for the lif of me i don't know what

[Ben502]

and just one more follow up and then i will shut up...

i have gone through again and tested the site on IE7,8,9 , Firefox, Chrome, Safari and my android browser and i have not been able to see the same result that my client sees. A friend of mine got it to do it for a second in Safari for mac but it fixed it's self as he resized his screen then it never did it again.

Is there a point when i just tell the lovely client "i think it is just your computer cause i cannot replicate the problem."

she is also having an issue of the "w"s looking washed out on her screen...but no other computer has the issue...

thank you all very much for reading all my ramblings and i welcome any insight on this one...

[lucy24]

she is also having an issue of the "w"s looking washed out on her screen...but no other computer has the issue...

You mean the letter w? As in "W is for washed-out"?

I'd love to suggest that her computer is washed-up, but if it supports MSIE 9 there should be some life in it yet. Maybe it's time to make some casual remark that will terrify her into running straight for the nearest Computer Geek to perform some expensive and time-consuming virus scans and firmware upgrades. Along the way, he will accidentally fix whatever the div-width problem was.

[Ben502]

indeed...the letter "w" it is random at best but i have seen it on a screen shot she has sent me. i have asked her to go look at the site on someone else's computer

sadly i have spent the day trying to fix the div issue (that i cannot replicate) when i should have been working on another clients site.

thank god i have bourbon.

[alt131]

thank god i have bourbon.

hmmm ... if bourbon is the solution to code problems I'll take a train-load please ;)

Being serious, I can't reproduce the issue here with some invented html as I'm not sure exactly what the structure is. However, given this has to do with browser re-sizing, and has been momentarily seen on another set-up, it does sound like it could be a redraw issue.

However, some other thoughts - have you validated the css and html to double-check for errors?

it looks like the body tag is squashing any of the other elements i have set to 100% as the window size changes.
for testing, i set the body tag to 2000px wide. at that point all of the "squashed" elements looked fine (container, header color, footercolor).

If you mean all elements are reducing in width as the window resizes, that is correct. As body is width:100%, it will always be 100% of the viewport width, and any child elements with width:100% will be that width as well. So any "squishing" should be a result of something in the code, such as elements with a fixed width colliding with elements with width auto, or floated or positioned elements.

You have position:relative on #container - are any other elements positioned?

Also, you haven't said how much of the background is exposed - if only a few px, could this just be a rounding issue?

[Ben502]

it also sounds like a redraw issue to me. i am just glad to hear someone else say it.

I just grabbed one of the pages at random on the site and ran the W3C validation on the html and the css. minus a couple of Alt tags, all came back good.

I had the container set to relative for when i was playing with sticking the footer to the bottom at all times at my graphics guys request. For this particular site, that does not work.

it looks like it is more that just a few pixels when it does reduce the header and footer (which are set to 100%) the only place i can make it happen is dreamweaver though which i am assuming is rendering this in an odd way anyway. All my browsers seem to work with it.

Bourbon train incoming!

Thanks again!

[Marshall]

Assuming the #headercolor is inside the #container, try removing position: relative; from #container and setting both to margin: 0 auto; which will center the DIV.

[Ben502]

done. and in dreamweaver splitscreen mode, no love.

[Ben502]

OK! I GOT IT TO DO IT IN CHROME!

so, if i restore the screen down and the resize it by dragging the screen horizontally so that my browser window is smaller than my fixed image (960 px) so that i get a scroll bar at the bottom of the screen and i scroll it over to the right, then the header and footer are now smaller...

so i guess this begs the next question of what do i need to do to make sure that my header and footer color that i want to fill the entire screen,horizontaly, always fill the space?

of course it looks like facebook does the same thing...so maybe it ain't just me?

[Ben502]

SUCCESS!

ok..so...what i have done to "fix" the problem is also set my fixed elements in the header to the same color as the "headercolor" that way when it shrinks due to window re-size it is not as obvious

[alt131]

Ben, great that you found a fix, but I still wonder about this:

so, if i restore the screen down and the resize it by dragging the screen horizontally so that my browser window is smaller than my fixed image (960 px) so that i get a scroll bar at the bottom of the screen and i scroll it over to the right, then the header and footer are now smaller...

If you mean the colour header and footer "ends" as you scroll to the right, so the elements with a fixed width appear to protrude out of the body to the right - something like this:
//////////parent//////
/////////////////////
**********fixed width element******
******************************
////////////////////
///////////////////

That is correct behaviour as the elements with width:100%, or block elements with no width that will automatically expand the full width of the viewport are obediently re-drawing themselves to 100% of the viewport width on resize. However elements with an explicitly set width that is greater than the viewport will overflow and force the scroll bar. Observe this in action by setting a border on the width:100% elements then resizing the viewport as you describe.

Your description suggests the desired layout is for elements that currently have width:100%/auto to never re-size less than the width of the smallest fixed-width element. If I am right, that is a fixed-width layout and rather than setting background-colors to "hide" the fluid width, I'd suggest a better solution would be to tell the browsers what you really want by setting a min-width on the parent containers.

However, also note this seems the opposite of the problem reported in the OP - which seemed to be that the fixed-width elements were resizing smaller than their explicitly set width leaving the colours of the parent elements exposed even though the viewport width should have been wide enough to contain them.

[Ben502]

i may have not expalined the problem correctly in the OP. The fixed width items were not the problem, it was the items such as "headercolor" which were set to 100% wide. I assumed (and it looks like incorrectly) that if the body was set to 100% and i can always see it's background color, that other elements also set to 100% and not withing a fixed width div would always stay full across my browser window and not shrink. (lesson learned).

I do apologize if my description was bad. I did not think to trouble shoot the problem by shrinking my browser window down to being scrollable

[alt131]

Hey Ben, no troubles - my concern is just making sure we have identified and found the solution/understanding of the actual/full issue.

.. must admit those washed-out "W's" still have me intrigued! Clear-type settings, perhaps? Or should we just "quit while ahead" ;)

[Ben502]

i got nothing on the w's...and is not all of them either...maybe i should have her check the M's?

for all seriousness though, thank you a ton. just having a place to keep putting together what i was finding and to have some other folks confirm that i am not nuts is a HUGE help.