2-Column div's

problem with re-size

[Hagstrom]

I'm trying to use CSS for placing my text up front in the HTML code. I do this with two floating DIV's:

<div style="float:right; width:75%; margin:0px;padding:0px">
Sed ut perspiciatis unde omnis iste natus error sit voluptatem 
accusantium doloremque laudantium, totam rem aperiam, eaque ipsa 
quae ab illo inventore veritatis et quasi architecto beatae vitae 
</div>
<div style="float:left; width:25%; margin:0px;padding:0px">
Menu
</div>

The strange part is that for some window-widths, the left menu falls down to a position lower than the right hand column. If I slowly re-size the window, the word "Menu" will jump up and down.

I can circumvent it by using column-sizes that add to less than 100% (eg: 24% and 75%). But could anyone explain to me what's going on?

[isitreal]

Have you set body, html {margin:0; padding:0;}?

I think the solution you found, to set it at 99% of total width though is a reasonable one, I do that because I use 1px borders, which adds 1 px to the 100%, so you have to drop it down to 99.6% or so for mozilla/opera, which correctly make it 100% + 1, same would go I think if there is padding on the body, or undeclared padding.

It's better to use a slight tweak like that than to risk your page totally breaking up in a completely unacceptable way.

[Hagstrom]

Have you set body, html {margin:0; padding:0;}?

I have (now) but it doesn't make a difference.

But even if a margin or padding had "stolen" a few pixels, it wouldn't explain why the left column jumps up, down, up, down, etc. as you slowly resize the window.

It's better to use a slight tweak like that than to risk your page totally breaking up in a completely unacceptable way.

I agree - and I have just done it. But just for once I would like to know what I'm doing ;)

[isitreal]

Float is a very weird thing, also a linebreak between div , td, anything really, can be interpreted as a single character space at times, that's how this:
<p>
hello
world
</p>
display with a space between hello and world on your screen.

If you set the two columns as absolute:

#column1 {position:absolute;left:0;top:0;width:75%;}
#column2 {position:absolute;left:75%;top:0;width:25%;}

You'll get more reliable display, but maybe other problems will popup. None of these problems will surface if you use a simple table to make this layout, needless to say.

[SuzyUK]

But just for once I would like to know what I'm doing

Hagstrom what you're doing, by reducing the percentage width is allowing for "pixel rounding differences"

You have a container wether that's the screen width or a container div doesn't matter... that is your layout width.

Then you make your "columns" 25%/75% respectively. Browsers will handle the rendering differently (it would be easy if we could be assured that browswers would round up/down according to the law of maths.. but they don't ~ guess who does it differently!)

e.g. if the user is viewing at a screen width of 883px
25% of 883 = 220.75 which rounded up is 221px
75% of 883 = 662.25 which rounded up is 663px

which added together makes the total width 884px, which is 1px too many for our 883px width, therefore one of the columns will move.. this might not happen when the viewing at 884px because

25% of 884 = 221px
75% of 884 = 663px

added together this does equal 884px which is fine so it lines up accordingly

This is why in some browsers.. when you drag the screen widthways sometimes it works sometimes it doesn't.

This is probably a case for non pixel perfect designing. (that's were you're using the 99% you're narrowing the perfection ratio) note you're not perfecting it you're just narrowing the perfection calculation!

However if you're using a "container" div already and it is a fixed width, you can then be sure that your percentages will always be divisible with no rounding required.. i.e. make your container width divisible by your percentages so it requires no rounding and it should always work.

I don't thnk I described that very well..

but ask questions it'll get there

Suzy

[isitreal]

I think you described that extremely well, personally anyway, thanks suzyUK, I hadn't thought of that, since I almost always use primary containers for all my pages, so I haven't run across this issue except in testing, but your explanation completely cleared that point up for me at least, can't speak for anyone else.

[Hagstrom]

SuzyUK, you described that very well and it explains the situation perfectly.

Isitreal, the “position:absolute” probably won’t work together with other elements on the page (like headers and footers).

I know tables work, but I’m slowly replacing tables wherever CSS should be able to do the trick.

Thanks to you both

[isitreal]

Your right, once you need a footer you're going to run into problems, that's one of the more common problems I'm seeing people run into here with div layouts.

Personally, rather than phasing out table layouts I'm starting to phase in div layouts, following purplemartin's basic guideline of if you are dealing with a basic rectangular page structure, top header, left bar, content area, footer, then use a table, if you are dealing with a looser, less rigid layout, use divs. This approach has worked very well, on the last two sites I did, I picked the right tool for the job, both ended up being up in a day, both are very stable, both load in about 3 seconds over dialup for first page (because of the CSS), 1 second per page after that, both are full CSS, no page formatting, and both are very stable crossbrowser, and both validate as zero error. One is a a basic table, with divs for all other page formatting, the other positioned divs.

Making the one I made with a table as primary page container, divs for all other page layout within the 3 primary cells, with all divs would first of all not have worked, and second of all would have taken me at least twice as long to get up, with huge sacrifices in stability.

[Jessi]

I don't think it's so hard with divs if you have the right article to refer to! Try this:

[maxdesign.com.au...]

It's a layout with header, nav bar and content area, and footer. Works for me.

Let's see if I can describe how it works: You have a container for all the divs for the areas mentioned above. The nav bar is a div that is floated to one side of the container and has a specified width. The content area is a div, also inside the container, that has a large enough margin that it will give plenty of room for the nav bar. The footer uses clear:both.

Is this what you're looking for?

p.s. I have no connection with the site except that I'm very happy to have stumbled upon it, and I think the guy writes tutorials like a dream.

[Jessi]

I forgot to post the same guy's page that explains the principle:

[maxdesign.com.au...]

Please forgive me if I'm not on the actual track of the thread, as I'm a newbie. Sometimes I find it a little tricky keeping track of the topic.

[Hagstrom]

Close - but no cigar :)

First of all the guy uses fixed widths (200px for the navigation bar and 400px for the content) which, of course, will save him from any resizing problems.

Secondly, only the navigation bar is floated (so the title of his page is a bit misleading ;) ). The content is fixed in position 200px. This will save him from the problems mentioned in this thread, but the whole point of my two div's was to move the content-div up front in my HTML-code - and for that you need to float both div's.

Nice looking site though :)

[Jessi]

how about the following adaptation?

body {
font-size: 90%;
background:blue;
text-align:center;
}

#container {
width:42em;
margin:0em auto;
text-align:left;
background:#ffffff;
}

#header {
width:42em;
height:3em;
background:red;
}

#content {
float:right;
width:24.5em;
background: #ffffff;
}

#navigation {
width:15em;
margin:0 26.5em 0 0 ;
}

#footer {
clear: both;
background-color: red;
}

This is what I do on my own site except that I float the content left instead of right, and set the left margin of the navigation. I just switched them, and voila. And the content div comes first in my html, ahead of the navigation, I mean. Is that helpful or am I off the track again?

ps I had been using some padding so you can probably play with the widths of the navigation and content and what they add up to

pps the text-align stuff is for the benefit of IE so that centering works properly

[SuzyUK]

Hagstrom..

I shouldn't think you need to float both columns.. you want the content to come first in the HTML so you should only then need to float it to whichever side you want.

Then the navigation div will automagically fit into the space leftover without a float or a width declared on it which will sort the "jumping" difference too (It no longer jumps because it is no longer being "forced" to calculate/round up pixels for the width to total 100% it is adjusting the nav div to fit instead.. by default.)

although this will then cause the nav div to wrap under the content if it gets longer than the content section so just put a margin of 75% onto the approriate side of the nav...

e.g.

.right {float: right;
width: 75%;
margin: 0;
padding: 0;
background: #eee;
}

.left {
margin: 0 75% 0 0; /*right margin*/
padding: 0;
background: #ffc;
}

or alternatively check out this thread [webmasterworld.com] which has a newly discovered technique for two column layouts msg#7 (it's been tested very stable and can have a header/footer too). It's demo'd on there using pixels but it works just as well with percentages and the sidebar can be swapped to either side as detailed in message too.

Suzy

[Hagstrom]

You're right, both of you. I stand (happily) corrected.

SuzyUK, your example works fine so I'll use that. All things being equal, having one floating object should be robust than two.

I checked the other thread, but like I said "just for once I would like to know what I'm doing". I simply don't get the point of the double wrapper - and what is a negative margin supposed to do? The CSS1 & CSS2 specs say "A negative value is allowed, but there may be implementation-specific limits." That doesn't sound very comforting?

Be assured that your seeds have not been sown on stony ground.