Float margin: Mozilla vs. IE + Opera

Why is mozilla different?

[johnnie]

How do I circumvent the inconsistency that browsers exhibit when rendering a floated div next to a non-floated div? In Opera and IE, the float takes up no space, so the menu must be margined menuwidth+space. In mozilla however, the float takes up document space, which requires a margin of just the space you want between the two.

For example, I use the following CSS:

#menu
{
width: 11em;
float:left;
font-size: 0.9em;
}
#content
{
margin:0.5em 0 0 10.5em;
border:2px solid #00A;
padding: 0.5em 0.5em 0 0.5em;
width: 80%;
height: 86%;
overflow: auto;
}

IE and opera render the menu and the content right next to eachother (the float takes up no document space), but in mozilla I see the content box jumping 10.5em to the right of the menu. I think mozilla is right here, but well... How do I make sure all the browsers get it right, regardless of tacky standard implementation? Is there a hack to fix this issue?

[durumpoulet]

i don't use floating a lot, but i guess the first hack i can think about would be to declare two times the values, once for IE/Opera and once for Moz

#content /* for ie¦opera */
{
padding:...
}

html>body #content /* for geckos */
{
padding:...
}

[createErrorMsg]

In Moz, the width of a box is width + margin + padding + borders. So your #content box has a width of 80% PLUS 10.5em(the left margin).

In iE (assuming it's 5.x or 6 in Quirks mode), box width equals the width setting, with margins, etc stuffed inside.

Sounds like what's happening here, yes? IE puts the 10.5em margin INSIDE the 80% width. Moz ADDS it to the outside.

I was unaware of Opera behaving in this way, but I suppose it's possible.

Solution: make it so width + margin equals your desired width. Then use the star hack to feed IE it's version of things...

#content {
width: WHATEVER NEW WIDTH SETTING IS FOR MOZ;
}

* html #content {
width: 80%;
w\idth: WHATEVER NEW WIDTH SETTING IS FOR MOZ;
}

Come to think of it, this hack is frequently followed by the "Be nice to Opera hack." I'm not real familiar with it, but it's ubiqtuous presence implies that Opera, too, has box model issues.

(The * html selector feeds these properties to IE browsers. The w\idth setting then feeds IE6 in Standards mode the correct width setting for it's correct box model.)

Your biggest challenge here looks like figuring out how to deal with the mixed EM and % widths.

[johnnie]

Well, I have tried numerous hacks and methods (finding: the '*7-hack' doesn't render in firefox eiter), but I can't get it to work. Using child selectors I can seperate IE from mozilla, but there is no way I can make opera ignore something that mozilla reads...

I now have the situation in which mozilla and IE display correctly, but opera messes up. The problem lies in the fact that mozilla and opera display differently, but will read the same rules...

Is there even a solution?

[SuzyUK]

johnnie.. no solution yet.. but I have to say this sounds like a rare Moz problem.

Take out the overflow: auto and all browsers render more or less the same. I say more or less the same because IE's float model is causing the 80% width requirement to be on 80% of the remaining space whereas Moz/Opera are making the content 80% of the viewport.. they are correct, and I would tackle that particular issue by margining the right side of the content area instead of using a width.. but I don't know which of these effects you are after so we can make that another question ;)

but the strangeness is that overflow: auto; is the property that is triggering the non-floated div not to take it's position from the left hand side of the page in Moz, which is weird because it's normally the most compliant when it comes to floats.

I've found a Mac forum which iterates the same problem and it says that it happens with Moz and safari.. I believe Safari also has very good CSS support so does this suggest there is something in the CSS specs re: floats/overflow?

I'm reading some specs as we speak but am posting this to see if anyone else has noticed this before?

How to fix though I don't know exactly yet, but perhaps a wrapper div for the content might be able to be used, putting the scroll feature on the inner div?

Suzy

[SuzyUK]

OK I think this is it: CSS2.1 Block Formatting Context [w3.org]

The quote (with my bold):

Floats, absolutely positioned elements, inline-blocks, table-cells, and elements with 'overflow' other than 'visible' establish new block formatting contexts.

......

In a block formatting context, each box's left outer edge touches the left edge of the containing block (for right-to-left formatting, right edges touch). This is true even in the presence of floats (although a box's line boxes may shrink due to the floats), unless the box establishes a new block formatting context (in which case the box itself may become narrower due to the floats).

So not sure if there's a technical right or wrong, but Moz are interpreting the "may" and are applying the margin from the new block formatted box and not the left edge of the containing block... hmmm

Therefore I think the best way to do this would be to use a wrapper div as I am unaware of any CSS hack that only targets Moz...

Suzy

[johnnie]

SuzyUK,

I don't know what you mean exactly with a wrapper div solving my problem, but I tried enclosing my content box within another (empty, styless) box, but that messes things up. Adding another box within the content that only has the overflow: auto property also messes up. I'll sticky you an URL where you can evaluate my CSS and see if you can devise a solution.

Thanks,

John

[SuzyUK]

johnnie..

using the example in your first post.. in theory amending it to this should help.

#menu {
width: 11em;
float:left;
font-size: 0.9em;
}

#contentwrap {
margin: 0.5em 0 0 10.5em;
border:2px solid #00A;
padding: 0.5em 0.5em 0 0.5em;
width: 80%;
height: 86%;
}

#content {
height: 100%;
overflow: auto;
}

HTML:
<div id="menu">menu stuff</div>
<div id="contentwrap">
<div id="content">
content in here...
</div>
</div>

but I tried enclosing my content box within another (empty, styless) box, but that messes things up

Yes that is what I meant but the theory above is the problem ;)

only one display issue arises in Moz because you cannot use the overflow property on your #content div.. so when you make the content div into a "wrapper" div (now #contentwrap) which doesn't have the overflow set it will honour the margin set to clear the float.. then nest another div inside this #contentwrap div (now #content) which only has to know what height (100%) to be so it can produce a scrollbar.. no margins involved etc..

but
I know from your code that there are other issues here now too because of margin/paddings/borders involved..so this theory should not be taken as a "pixel perfect" solution.

Your original code while seeming to display the same in IE and Moz was doing so for different reasons. (and a new one on me at that) So even once we correct for Moz's handling of overflow/floats/margins there are then the usual IE bugs (box model and float induced ones) coming into play and then it's down to how you feed different values to IE.

some hints/tips...

First off I would amend all the widths to ems instead of % so you can calculate what the different width values need to be. and be aware that top/bottom padding on elements with a height will also affect them too so perhaps it's best not to use top/bottom padding on the #contentwrap (or other main) divs instead controlling any required spacing by padding elements inside the divs in order that your 100% height on the scrolling div is not 100% + padding...

HTH...

Suzy