7  3403 
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.
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
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
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.
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
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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
...
|
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...
|
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;...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
