Margin-bottom of last child in overflowed block is not rendered

**Ben C** · Jun 27 '08, 07:19 PM

Re: Margin-bottom of last child in overflowed block is not rendered

On 2008-06-06, GTalbot <newsgroup@gtal bot.orgwrote:

Hello fellow authoring.style sheets colleagues,
>
Can someone please explain why the bottom margin of the last inflow
block-level child in an overflowed parent should not have its margin
reachable.

It all depends whether you consider margins to be "content" or not.

I read and re-read carefully the CSS 2.1 spec and I just
can not see why.

The spec (CSS 2.1 11.1) says that overflow: scroll means you get some
mechanism to reach the "content". It doesn't really say anywhere whether
margins count as content (although space is usually reserved for them in
containing elements' "content areas").

Personally I don't think margins should be considered to be content. If
you think they should, then you have to explain how scrolling is
supposed to work when there are negative margins.

Consider this case:

<div style="overflow : scroll; width: 200px; height: 200px;
border: 1px solid black">
<div style="width: 200px; height: 200px; margin: 20px;
border: 10px solid blue">
</div>
</div>

In Firefox 2 I can scroll down and find a 20px gap at the bottom. But if
I scroll to the right there is no corresponding 20px gap there.

Why not? Well if you read the spec (10.3.3), the used value of the inner
div's right margin is -60px, even though I set it to 20px. Its used
bottom margin however is still 20px.

So there simply is no 20px gap to the right. If anything there is a gap
of -60px. Is that "negative content"? Should the browser not let you
even scroll as far as the right border because of the negative right
margin? Well that would obviously be silly.

What Firefox 2 is doing is reasonable and doesn't violate the spec, but
I can't see how it's particularly helpful.

If you want a left or right margin that you can scroll to you need to
put a shrink-to-fit wrapper around the inner div, effectively putting
its margins into the content area (and I use the word content advisedly)
of this shrink-to-fit parent.

You can do just the same for the top and bottom margins in a browser
(unlike FF2) that didn't treat margins as content, if you wanted to be
able to scroll through them, although you would need a pixel of bottom
padding to prevent collapsing.

If you have some free time, I tried to explain this in www-style:

Re: Overflow and Margins from Ben Cotterell on 2008-02-05 (www-style@w3.org from February 2008)

http://lists.w3.org/Archives/Public/www-style/2008Feb/0033.html

go back in the thread a bit too, but IIRC the early part of the
discussion was about padding on the parent element, which is a
no-brainer: that is always inside the parent's border box, regardless of
whether the contents overflow or not.

**Ben C** · Jun 27 '08, 07:19 PM

Re: Margin-bottom of last child in overflowed block is not rendered

On 2008-06-06, Ben C <spamspam@spam. eggswrote:
[...]

Consider this case:
>
<div style="overflow : scroll; width: 200px; height: 200px;
border: 1px solid black">
<div style="width: 200px; height: 200px; margin: 20px;
border: 10px solid blue">
</div>
</div>
>
In Firefox 2 I can scroll down and find a 20px gap at the bottom. But if
I scroll to the right there is no corresponding 20px gap there.
>
Why not? Well if you read the spec (10.3.3), the used value of the inner
div's right margin is -60px, even though I set it to 20px. Its used
bottom margin however is still 20px.

That's -40px not -60px. Negative anyway.

The idea is:

20 + 10 + 200 + 10 + x = 200
therefore x = -40

**GTalbot** · Jun 27 '08, 07:19 PM

Re: Margin-bottom of last child in overflowed block is not rendered

On 6 juin, 16:45, Ben C <spams...@spam. eggswrote:

On 2008-06-06, GTalbot <newsgr...@gtal bot.orgwrote:
>

Hello fellow authoring.style sheets colleagues,

>

Can someone please explain why the bottom margin of the last inflow
block-level child in an overflowed parent should not have its margin
reachable.

>
It all depends whether you consider margins to be "content" or not.
>

I read and re-read carefully the CSS 2.1 spec and I just
can not see why.

>
The spec (CSS 2.1 11.1) says that overflow: scroll means you get some
mechanism to reach the "content". It doesn't really say anywhere whether
margins count as content (although space is usually reserved for them in
containing elements' "content areas").
>
Personally I don't think margins should be considered to be content. If
you think they should, then you have to explain how scrolling is
supposed to work when there are negative margins.
>
Consider this case:
>
<div style="overflow : scroll; width: 200px; height: 200px;
border: 1px solid black">
<div style="width: 200px; height: 200px; margin: 20px;
border: 10px solid blue">
</div>
</div>
>
In Firefox 2 I can scroll down and find a 20px gap at the bottom.

In Firefox 3, you will not be able to scroll down and find that 20px
gap at the bottom. Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 do
not allow scrolling down all the way down to reach, to view that 20px
gap at bottom.
Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 all render your code
snippet in the same manner.

This new behavior in Firefox 3 is not reflected in section 10.6.3 ...

But if
I scroll to the right there is no corresponding 20px gap there.
>
Why not? Well if you read the spec (10.3.3), the used value of the inner
div's right margin is -60px, even though I set it to 20px. Its used
bottom margin however is still 20px.

Section 10.3.3 mentions that
"
If
[
margin-left, border-left-width, padding-left, width, padding-right,
border-right-width, margin-right, scrollbar width (if any), width of
containing block
]
all have a computed value other than 'auto', [then] the values are
said to be 'over-constrained' and one of the used values will have to
be different from its computed value.
"

and so the least damage one can do when resetting a value is to reset
the margin-right. No "real" content (css content) is lost.

But the problem is that there is no equivalent for margin-bottom as
explained in section 10.6.3. No correspondence. I do read
"(...) Similarly, if the bottom margin of the block does not collapse
with the bottom margin of its last in-flow child, then the content
ends at the bottom margin edge of the bottommost child."
section 10.6.3

Visual formatting model details

http://www.w3.org/TR/CSS21/visudet.html#normal-block

Maybe I do not understand what they mean with "ends at the bottom" ...

So there simply is no 20px gap to the right. If anything there is a gap
of -60px. Is that "negative content"? Should the browser not let you
even scroll as far as the right border because of the negative right
margin? Well that would obviously be silly.

I agree it would be silly.

What Firefox 2 is doing is reasonable and doesn't violate the spec, but
I can't see how it's particularly helpful.

It may not be particularly or specifically helpful but it is what the
web author wanted, expected, coded for. He wanted and requested a 20px
margin-bottom gap at the bottom of that 10px blue border. And as far
as specification is involved, I do not see how or why that 20px bottom
margin edge of the bottommost child should not be rendered.

Regards, Gérard

**GTalbot** · Jun 27 '08, 07:19 PM

Re: Margin-bottom of last child in overflowed block is not rendered

On 6 juin, 16:45, Ben C <spams...@spam. eggswrote:

If you have some free time, I tried to explain this in www-style:
>

Re: Overflow and Margins from Ben Cotterell on 2008-02-05 (www-style@w3.org from February 2008)

http://lists.w3.org/Archives/Public/www-style/2008Feb/0033.html

>
go back in the thread a bit too,

It starts here:

Overflow and Margins from Brad Kemper on 2008-02-02 (www-style@w3.org from February 2008)

http://lists.w3.org/Archives/Public/www-style/2008Feb/0000.html

Regards, Gérard

**Ben C** · Jun 27 '08, 07:19 PM

Re: Margin-bottom of last child in overflowed block is not rendered

On 2008-06-06, GTalbot <newsgroup@gtal bot.orgwrote:

On 6 juin, 16:45, Ben C <spams...@spam. eggswrote:

[...]

>Personally I don't think margins should be considered to be content. If
>you think they should, then you have to explain how scrolling is
>supposed to work when there are negative margins.
>>
>Consider this case:
>>
> <div style="overflow : scroll; width: 200px; height: 200px;
> border: 1px solid black">
> <div style="width: 200px; height: 200px; margin: 20px;
> border: 10px solid blue">
> </div>
> </div>
>>
>In Firefox 2 I can scroll down and find a 20px gap at the bottom.

>
In Firefox 3, you will not be able to scroll down and find that 20px
gap at the bottom. Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 do
not allow scrolling down all the way down to reach, to view that 20px
gap at bottom.

Good! I think that is the simplest and most reasonable interpretation.

Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 all render your code
snippet in the same manner.
>
This new behavior in Firefox 3 is not reflected in section 10.6.3 ...

No. 10.6.3 is a bit of a diversion: I just wanted to point out that if
margins are considered content (and therefore scrollable-to), although
that works fairly easily for vertical margins, it usually doesn't work
for horizontal margins since if the element has overflowed it usually
has used negative horizontal margins whatever the author set.

I conclude from this that the idea that "margins count as content" is a
bit problematic and unhelpful.

>But if
>I scroll to the right there is no corresponding 20px gap there.
>>
>Why not? Well if you read the spec (10.3.3), the used value of the inner
>div's right margin is -60px, even though I set it to 20px. Its used
>bottom margin however is still 20px.

>
>
Section 10.3.3 mentions that
"
If
[
margin-left, border-left-width, padding-left, width, padding-right,
border-right-width, margin-right, scrollbar width (if any), width of
containing block
]
all have a computed value other than 'auto', [then] the values are
said to be 'over-constrained' and one of the used values will have to
be different from its computed value.
"
>
and so the least damage one can do when resetting a value is to reset
the margin-right. No "real" content (css content) is lost.

Exactly (or the left margin in rtl).

But the problem is that there is no equivalent for margin-bottom as
explained in section 10.6.3. No correspondence. I do read
"(...) Similarly, if the bottom margin of the block does not collapse
with the bottom margin of its last in-flow child, then the content
ends at the bottom margin edge of the bottommost child."
section 10.6.3

Visual formatting model details

http://www.w3.org/TR/CSS21/visudet.html#normal-block

>
Maybe I do not understand what they mean with "ends at the bottom" ...

It is ambiguous, and it does sound from that paragraph as though margins
are supposed to be content.

But they are talking about how to work out the size of the content area
of a container with auto height.

That container's "content area" does end after the child's bottom margin
(assume no collapsing for the sake of argument-- e.g. the container has
a border), if the container has auto height.

So when they say "content" here do they mean the container's contents,
or the container's content area?

Note also that this section is entitled, rather weaselishly,
"Block-level non-replaced elements in normal flow when overflow computes
to visible".

>So there simply is no 20px gap to the right. If anything there is a gap
>of -60px. Is that "negative content"? Should the browser not let you
>even scroll as far as the right border because of the negative right
>margin? Well that would obviously be silly.

>
I agree it would be silly.
>

>What Firefox 2 is doing is reasonable and doesn't violate the spec, but
>I can't see how it's particularly helpful.

>
It may not be particularly or specifically helpful but it is what the
web author wanted, expected, coded for. He wanted and requested a 20px
margin-bottom gap at the bottom of that 10px blue border. And as far
as specification is involved, I do not see how or why that 20px bottom
margin edge of the bottommost child should not be rendered.

I don't think the spec is clear either way. In my opinion Firefox 2 is
not wrong, and neither is Firefox 3. But I find the interpretation of
Firefox 3 more logical, simpler, and more useful. Perhaps they will
reword to spec to make this clearer, especially as everyone seems to be
leaning towards this interpretation in the latest versions of their
products.

**GTalbot** · Jun 27 '08, 07:19 PM

Re: Margin-bottom of last child in overflowed block is not rendered

On 7 juin, 04:30, Ben C <spams...@spam. eggswrote:

On 2008-06-06, GTalbot <newsgr...@gtal bot.orgwrote:
>
>
>

On 6 juin, 16:45, Ben C <spams...@spam. eggswrote:

[...]

Personally I don't think margins should be considered to be content. If
you think they should, then you have to explain how scrolling is
supposed to work when there are negative margins.

>

Consider this case:

>

>

In Firefox 2 I can scroll down and find a 20px gap at the bottom.

>

In Firefox 3, you will not be able to scroll down and find that 20px
gap at the bottom. Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 do
not allow scrolling down all the way down to reach, to view that 20px
gap at bottom.

>
Good! I think that is the simplest and most reasonable interpretation.
>

Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 all render your code
snippet in the same manner.

>

This new behavior in Firefox 3 is not reflected in section 10.6.3 ...

>
No. 10.6.3 is a bit of a diversion: I just wanted to point out that if
margins are considered content (and therefore scrollable-to), although
that works fairly easily for vertical margins, it usually doesn't work
for horizontal margins since if the element has overflowed it usually
has used negative horizontal margins whatever the author set.
>
I conclude from this that the idea that "margins count as content" is a
bit problematic and unhelpful.
>
>
>

But if
I scroll to the right there is no corresponding 20px gap there.

>

Why not? Well if you read the spec (10.3.3), the used value of the inner
div's right margin is -60px, even though I set it to 20px. Its used
bottom margin however is still 20px.

>

Section 10.3.3 mentions that
"
If
[
margin-left, border-left-width, padding-left, width, padding-right,
border-right-width, margin-right, scrollbar width (if any), width of
containing block
]
all have a computed value other than 'auto', [then] the values are
said to be 'over-constrained' and one of the used values will have to
be different from its computed value.
"

>

and so the least damage one can do when resetting a value is to reset
the margin-right. No "real" content (css content) is lost.

>
Exactly (or the left margin in rtl).
>

But the problem is that there is no equivalent for margin-bottom as
explained in section 10.6.3. No correspondence. I do read
"(...) Similarly, if the bottom margin of the block does not collapse
with the bottom margin of its last in-flow child, then the content
ends at the bottom margin edge of the bottommost child."
section 10.6.3
http://www.w3.org/TR/CSS21/visudet.html#normal-block

>

Maybe I do not understand what they mean with "ends at the bottom" ...

>
It is ambiguous, and it does sound from that paragraph as though margins
are supposed to be content.
>
But they are talking about how to work out the size of the content area
of a container with auto height.
>
That container's "content area" does end after the child's bottom margin
(assume no collapsing for the sake of argument-- e.g. the container has
a border), if the container has auto height.
>
So when they say "content" here do they mean the container's contents,
or the container's content area?
>
Note also that this section is entitled, rather weaselishly,
"Block-level non-replaced elements in normal flow when overflow computes
to visible".

Yes, good point. They should have created a sub-section for when
overflow
does not compute to visible. This really could and should be improved.

>

So there simply is no 20px gap to the right. If anything there is a gap
of -60px. Is that "negative content"? Should the browser not let you
even scroll as far as the right border because of the negative right
margin? Well that would obviously be silly.

>

I agree it would be silly.

>

What Firefox 2 is doing is reasonable and doesn't violate the spec, but
I can't see how it's particularly helpful.

>

It may not be particularly or specifically helpful but it is what the
web author wanted, expected, coded for. He wanted and requested a 20px
margin-bottom gap at the bottom of that 10px blue border. And as far
as specification is involved, I do not see how or why that 20px bottom
margin edge of the bottommost child should not be rendered.

>
I don't think the spec is clear either way. In my opinion Firefox 2 is
not wrong, and neither is Firefox 3. But I find the interpretation of
Firefox 3 more logical, simpler, and more useful. Perhaps they will
reword to spec to make this clearer, especially as everyone seems to be
leaning towards this interpretation in the latest versions of their
products.

I wish cases like that would be utterly clear, explicit, even with a
diagram,
picture, schema, etc. so that no one loses a sec. trying to figure
things out.

I read the w3 email list (read all I could, tried to closely
understand... but couldn't very well).
Brad Kemper has a point: I agree with him when he says that it is
counter-intuitive.
The way it is implemented is/will be counter-intuitive for web authors
(I'm not saying
there isn't a *good* ... although not sure I see one good ... reason
for this sort of
behavior). From your example

<div style="overflow : scroll; width: 200px; height: 200px;
border: 1px solid black">
<div style="width: 200px; height: 200px; margin: 20px;
border: 10px solid blue">
</div>
</div>

a beginner, intermediate and even an experienced web author will
assume or will
presumably reach the conclusion that the browser(s) must be wrong or
it must
be a bug... because the 20px bottom margin disappear.

Thank you for your time and assistance,

Regards, Gérard

**Ben C** · Jun 27 '08, 07:19 PM

Re: Margin-bottom of last child in overflowed block is not rendered

On 2008-06-07, GTalbot <newsgroup@gtal bot.orgwrote:

On 7 juin, 04:30, Ben C <spams...@spam. eggswrote:

[...]

But the problem is that there is no equivalent for margin-bottom as
explained in section 10.6.3. No correspondence. I do read
"(...) Similarly, if the bottom margin of the block does not collapse
with the bottom margin of its last in-flow child, then the content
ends at the bottom margin edge of the bottommost child."
section 10.6.3
>http://www.w3.org/TR/CSS21/visudet.html#normal-block

>>

Maybe I do not understand what they mean with "ends at the bottom" ...

>>
>It is ambiguous, and it does sound from that paragraph as though margins
>are supposed to be content.
>>
>But they are talking about how to work out the size of the content area
>of a container with auto height.
>>
>That container's "content area" does end after the child's bottom margin
>(assume no collapsing for the sake of argument-- e.g. the container has
>a border), if the container has auto height.
>>
>So when they say "content" here do they mean the container's contents,
>or the container's content area?
>>
>Note also that this section is entitled, rather weaselishly,
>"Block-level non-replaced elements in normal flow when overflow computes
>to visible".

>
Yes, good point. They should have created a sub-section for when
overflow does not compute to visible. This really could and should be
improved.

What they're really driving at (I think) there is the fact that if
overflow does not compute to visible then the box starts a block
formatting context and so includes floats in its height calculation. See
10.6.6 "Complicate d cases" which links directly to 10.6.7.

[...]

>I don't think the spec is clear either way. In my opinion Firefox 2 is
>not wrong, and neither is Firefox 3. But I find the interpretation of
>Firefox 3 more logical, simpler, and more useful. Perhaps they will
>reword to spec to make this clearer, especially as everyone seems to be
>leaning towards this interpretation in the latest versions of their
>products.

>
I wish cases like that would be utterly clear, explicit, even with a
diagram, picture, schema, etc. so that no one loses a sec. trying to
figure things out.

Yes, they should clarify it. I expect they will in a later revision.

I read the w3 email list (read all I could, tried to closely
understand... but couldn't very well). Brad Kemper has a point: I
agree with him when he says that it is counter-intuitive. The way it
is implemented is/will be counter-intuitive for web authors (I'm not
saying there isn't a *good* ... although not sure I see one good ...
reason for this sort of behavior). From your example
>
><div style="overflow : scroll; width: 200px; height: 200px;
border: 1px solid black">
<div style="width: 200px; height: 200px; margin: 20px;
border: 10px solid blue">
</div>
</div>
>
a beginner, intermediate and even an experienced web author will
assume or will presumably reach the conclusion that the browser(s)
must be wrong or it must be a bug... because the 20px bottom margin
disappear.

20px on the bottom may be intuitive on its own, but then the author may
be surprised to find no 20px on the right (because of the negative used
right margin). So all things considered I think having neither 20px gap
(like FF3) is more intuitive. The fact that the spec frequently makes
use of the idea of negative margins to position things implies that
they're better thought of as offsets than as actual objects that take up
space.

Margin-bottom of last child in overflowed block is not rendered

Margin-bottom of last child in overflowed block is not rendered

Comment

Comment

Comment

Comment

Comment

Comment

Comment