On Jan 13, 2008, at 1:19 AM, Alan Gresley wrote:
> Philippe Wittenbergh wrote:
>> 2. Safari vs Firefox and Opera 9.5b. The right column is pushed far
>> away to the right in Firefox and Opera. Browsers have different
>> interpretation of how the margin on elements adjacent to a floated
>> block should behave.
> Philippe, I seeing different at my end. Safari 3 and Opera 9.1~9.2
> seems to show correct with the #scrollable div with overflow:auto
> sitting to the right of the #links floated left though the scroll
> bar of the #scrollable div sits outside the container. Opera 9.5
> and IE 7 shows the #scrollable div sitting below the footer but
> under the space it should be. IE 5 and IE 6 show like each other, a
> complete mess. A simplefied demo.
Because the container is not large enough to contain all elements
side by side. I did mention that in my message. It is specified as
1125px but should be 1130px .
The fact that Gecko shows the scrollable column next to the float is
a (known) bug (unrelated to the margin-left issue). Safari with
transitional doctypes is quirky; I never use that doctype.
>> It doesn't help that the css 2.1 docs was change recently regarding
>> this issue (essentially making the behaviour in Safari correct) .
>> You can solve this: set the margin-left on #scrollable to '0' (zero).
>> 3. your #container should be 5px wider to accommodate the content,
>> #header and #footer 15px wider.
>>  <http://www.w3.org/TR/CSS21/visuren.html#floats>
>> The 5th paragraph is relevant here. Before the latest version, it
>> stated that the horizontal margin should not collapse/slide under the
>> floated block; the reverse is through now.
> The change as I see in the specs is "Specified that the border box
> of a table, block-level replaced element, or element in the normal
> flow that establishes a new block formatting context must not
> overlap any floats in the same block formatting context."
> Wouldn't that make Firefox (Gecko 1.7~1.9) correct. Overflow:auto
> establish a new block formatting context as I see in the specs ,
> part of which reads (edited).
No. The previous version of the spec specified:
The **margin box** of a table, a block-level replaced element, or an
element in the normal flow that establishes a new block formatting
That is what Gecko implements (and Opera 9.5b)
The current version says 'border-box' (validating the behaviour WebKit).
> "Floats, absolutely positioned elements, inline-blocks, table-
> cells, table-captions, 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. This is true even in the
> presence of floats, unless the box establishes a new block
> formatting context"
> So the left margin (box's left outer edge) specified on the
> #scrollable div is pushing the #scrollable div away from the #links
> div in Firefox (correct).
That was correct per older version of 9.5 but no anymore per the
The current version says that the border-box cannot overlap the
floated box. It does not say (anymore) that the left margin of the
(scrollable) box should start at the right edge of the floated block.
> In the other browsers (not Opera 9.1~9.2) the same left margin is
> forcing the #scrollable div to render under the #links div as if
> the #scrollable div was a float. IE is doing the same but that is
> also due to hasLayout for this browser.
The scrollable div drops below the float because the parent box is
not wide enough, see above, confirmed by your test case linked below.
 floated box: width: 225px; padding-left: 15px; padding-right: 5px;
scrollable box: width: 500px;
margin-left: 385px; (on the floated box)
500+245+385 = 1130px
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/