How big an a rounding error be?

I guess I have always figured that if you had two of side-by-side floated elements, the max TOTAL rounding error would be 2px. But maybe this is not the case or even the problem at hand…

I am using overflow:auto to self clear an element. This is giving me scrollbar , horizontal in FF and vertical in Safari and Chrome. Yes, I know I could use overflow hidden and not SEE the scroll bars, but to me what this really indicates is that some content is larger than the size of the container… It’s also disconcerting that the scrolls have different orientations in different browsers.

Th problem can be seen here.

A test I did … basically concerning the simplified mark up and CSS is here. and shows no sign of the problem… so I am thinking is something , maybe an overwriting rule I am not noticing, ELSEWHERE in my actual page’s CSS… but I cant for the life of me figure out where. :frowning:

Additionally i was able to “hack” a solution… using #sec{margin-left:-4px; } Again not my preferred solution… and it took 4px!!! … which is why I wondered since I have 2 elements floated side-by-side ( widths 70/30) could the total rounding error be 4px!?

I really would appreciate some insight on this from the wise folk in the forum, as always.

Hi dresden,

It looks like your -moz-box-shadow on the #checkForm is giving you the horizontal scrollbar in FF. At least it goes away when I disable the box-shadow rule.

I’m curious as to why you are using % widths (70 & 30) on your inner divs (columns) when your #cont div is set at 960px.

<div id="cont" class="center">

.center {margin:0 auto; width:960px;}

Why not go ahead and use a px width on the columns, or are there other pages that get a fluid width on that .center class?

Yes, I know I could use overflow hidden and not SEE the scroll bars, but to me what this really indicates is that some content is larger than the size of the container… It’s also disconcerting that the scrolls have different orientations in different browsers.
I think what I mentioned above may have something to do with that but I never use “auto” for float containment as it is just to inclined to errors.

Additionally i was able to “hack” a solution… using #sec{margin-left:-4px; } Again not my preferred solution… and it took 4px!!! …
I have used (and not opposed to it) a negative margin to soak up rounding errors when my total column widths equal 100%. It’s usually not very noticeable and it has always worked for me. Though the way your page is set up you could have just as easily used 69% instead of 70.

Take a closer look at those box-shadows, it looks like the culprit to me.

Razur…

Thanks for the input!!! I knew it would be something stupid like that ( especially since the page was working fine at some point … and the poof! scrollbars.)

The annoying thing is that the box-shadow property is not supposed to affect the box-model… but this is not the only occasion that I have seen it do so. I will have to keep an eye out on that from now on, but I have to say I am a little disappointed by this.

I think what I mentioned above may have something to do with that but I never use “auto” for float containment as it is just to inclined to errors.

I guess I was being obsessive. The way I look at it the errors are still there ( albeit by a few pixels) but just clipped in the overflow , and it was bugging me.

I have used (and not opposed to it) a negative margin to soak up rounding errors when my total column widths equal 100%. It’s usually not very noticeable and it has always worked for me. Though the way your page is set up you could have just as easily used 69% instead of 70.

Yes, you are right, I was just being obsessive… working mathematically rather than visually. Which BTW , was part of the reason I coded using %s the idea was… i could change the page width w/o sifting through my all my code and recomputing all my container sizes. I figured I used easy numbers ( like 70/30 or 75/25… or such) to minimize any rounding errors and neg-margin and child-element padding to compensate … but I was thrown off by seeing such a relatively large “rounding error” … especially when firebug said there was NO ROUNDING ERROR at all. O.o !!

The annoying thing is that the box-shadow property is not supposed to affect the box-model…
Right, I have seen it happen before too. Here is what the specs (as they stand now) have to say about it.

Shadows do not influence layout and may overlap other boxes or their shadows. In terms of stacking contexts and the painting order, the outer shadows of an element are drawn immediately below the background of that element, and the inner shadows of an element are drawn immediately above the background of that element (below the borders and border image, if any). If an element has multiple boxes, all of them get drop shadows, but shadows are only drawn where borders would also be drawn; see ‘box-decoration-break’.
Shadows do not trigger scrolling or increase the size of the scrollable area.

Working with your revised code I used inline-block as a float containment method for testing in place of overflow:auto;

I set some BG colors also to show what is happening. You can see the box-shadow layering over the main content on the left side.


#cont_S{
background: url(images/nemrac_body_top.gif) repeat-x left top #dcdcdc;
[COLOR=Blue]text-align:center;[/COLOR]
}
#cont {[COLOR=Blue]display:inline-block;vertical-align:bottom;text-align:left;background:blue[/COLOR]}
#main, #sec{float:left; padding:20px 0 ;}
#main{width:70%;[COLOR=Blue]background:lime[/COLOR]}
#main .story{ margin:0 35px 0 0 ;}
#sec{width:30%; [COLOR=Blue]background:yellow[/COLOR]}

No scrollbars or clipped shadows with that :slight_smile:

hmmm… seems inline-block is solving a lot of “overflow:auto/hidden” issues these days. ( only too bad that alternate code needs to then be written for IE , tho in this case I still needed to do so anyways)

I see. I guess reading that same specs quote, I would have been lead to believe that box-shadow wouldnt have an effect on size and scrolling… but they are doing so…lol.

( only too bad that alternate code needs to then be written for IE , tho in this case I still needed to do so anyways)
You wouldn’t have to write anything special for IE in that case.

IE6/7 will contain floats whenever “haslayout” is tripped. Actually display:inline-block is a haslayout trigger and unless you reset it to inline with the tripswitch it remains as display:block

Not only that, your 960px width on .center is also tripping haslayout.

display:table will also contain floats and like inline-block nothing special would be needed for IE6/7.
I tend to use it as an absolute last resort though since it has been known to cause problems too.

This is true. I gues sI was just thinking of IE Mac… that has REALLY BUGGY inline-block behaviour

BTW,
as long as am on the subject, sort of, of the effects of box-shadow on element size. One could asume by what the specs say, that you could give a page container shadows and that it would not cause scrollbars on the viewport. Theoretically, at least.


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Untitled Document</title>

<style>
html, body{height:100%;margin:0}

#page{
	min-height:100%;
	-moz-box-shadow:0 0 10px #000;
	-webkit-box-shadow:0 0 10px #000;
	width:960px;
	margin:0 auto ;
}
	.content {margin:0; height:500px; background:pink; width:50%;}

</style>
</head>

<body>

<div id="page">

<p class="content">hey! I am content</p>


</div>
</body>
</html>

Your code (theory) is working in Webkit but gives a vertical scrollbar in FF

FF box-shadow problem confirmed