473,226 Members | 1,373 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,226 software developers and data experts.

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

Hello fellow authoring.stylesheets 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. I read and re-read carefully the CSS 2.1 spec and I just
can not see why.

Related webpages:

http://www.gtalbot.org/BrowserBugsSe...tRendered.html

Mozilla related bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=47710#c36

WebKit related bug:
https://bugs.webkit.org/show_bug.cgi?id=13632#c4

IE beta feedback related bug (you need to be registered):
https://connect.microsoft.com/IE/fee...dbackID=344808

IE 8 beta 1 entry:
http://www.gtalbot.org/BrowserBugsSe...IE8Bugs/#bug71

CSS 2.1, section 10.6 Calculating heights and margins
* 10.6.3 Block-level non-replaced elements in normal flow when
'overflow' computes to 'visible'
and that section also covers when overflow: auto

Regards, Gérard
Jun 27 '08 #1
7 3389
On 2008-06-06, GTalbot <ne*******@gtalbot.orgwrote:
Hello fellow authoring.stylesheets 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:

http://lists.w3.org/Archives/Public/...8Feb/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.
Jun 27 '08 #2
On 2008-06-06, Ben C <sp******@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
Jun 27 '08 #3
On 6 juin, 16:45, Ben C <spams...@spam.eggswrote:
On 2008-06-06, GTalbot <newsgr...@gtalbot.orgwrote:
Hello fellow authoring.stylesheets 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
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
Jun 27 '08 #4
On 6 juin, 16:45, Ben C <spams...@spam.eggswrote:

<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>
If you have some free time, I tried to explain this in www-style:

http://lists.w3.org/Archives/Public/...8Feb/0033.html

go back in the thread a bit too,
It starts here:

http://lists.w3.org/Archives/Public/...8Feb/0000.html

Regards, Gérard

Jun 27 '08 #5
On 2008-06-06, GTalbot <ne*******@gtalbot.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
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.
Jun 27 '08 #6
On 7 juin, 04:30, Ben C <spams...@spam.eggswrote:
On 2008-06-06, GTalbot <newsgr...@gtalbot.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
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
Jun 27 '08 #7
On 2008-06-07, GTalbot <ne*******@gtalbot.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 "Complicated 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.
Jun 27 '08 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Tony Benham | last post by:
I'm having problems with a css layout where a margin is being inserted with the wrong width. I believe it's my css that's at fault since it is wrong in netscape 7.1, opera,7.11 and IE6 but I cannot...
4
by: Harlan Messinger | last post by:
What is *supposed* to be the way to specify the horizontal offset of (a) the list item's marker and (b) the list item's content? In particular, see ...
6
by: Haines Brown | last post by:
I find that when I use list-style-image with galeon or mozilla, padding is inserted between the symbol image and the following list text, while under IE 5.0 it seems to be inserted before the image...
13
by: Cool Guy | last post by:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>test</title> </head> <body> <div style="height: 100px; width: 100px;...
10
by: Alan Silver | last post by:
Hello, In my (seemingly) endless quest to understand CSS, I have yet another problem. Please look at http://www.kidsinaction.org.uk/ph/x.html in Opera, where you will see it how I expected. If...
3
by: Luciano A. Ferrer | last post by:
this is really strange... I cant find what is wrong... so, #botonera have a left margin of 18px, but IE make it 36px! If I put a margin of 30px, IE make it 60px! I am crazy? <!DOCTYPE html...
11
by: Pablito | last post by:
Hi at all into a page I wrote <style> body {margin-left:10%;margin-right:10%;text-align:justify;} </style> reading the page with FireFox the margin left is 10% but the right is 0% Why? How can...
19
by: Edward | last post by:
Why is it when I have a DOCTYPE line in my HTML then "margin" and "padding" are ignored? This happens in both inline and stylesheet styles. It happens for both XHTML and HTML doctypes. It...
2
by: Steve Richter | last post by:
I want my panel to have an inner margin. Problem is label text does not appear to recognize the margin. In this example, the TextBox aligns on the margin, the label does not: <asp:Panel...
5
by: Neviton | last post by:
Hi this is the html to generate the behavior: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http:// www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.