Position Absolute DIV with top: 0, in BODY is offset by Sibling PRE'sfont-size

I noticed something that does not make sense to me. I do not read this
NG regularly, so I hope I am not asking something that has been answered
before. Anyway...

The top value of a DIV is affected by the following
conditions:

* child of relatively positioned BODY (not static, not absolute)
* BODY has a PRE as a child
* DIV appears as a child of BODY before any other text node or any other
element having border, height or width.
* no border on BODY

Noticed in these browsers:
IE8, Chrome 2, Safari 4, Firefox 3.5, Seamonkey 1.1, Opera 10.

The result is that the testNode DIV is offset by the font size of the
PRE element.

http://dhtmlkitchen.com/ape/adhoctest/css/bodynows.html

#testNode is, from viewport edge, flush left and offset from the top by
the PRE's font size.

I expected #testNode to be at 0, 0.

Why do the browsers position #testNode from the top, based on the
font-size of the PRE element?

Adding a text node in BODY or a div with height before #testNode will
also cause testNode to be at 0,0.

Why is #testNode's top offset by the PRE's fontSize when BODY has
position: relative? Why does adding a border to BODY change that?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On 2009-09-19, Garrett Smith <dhtmlkitchen (AT) gmail (DOT) com> wrote:

I noticed something that does not make sense to me. I do not read this
NG regularly, so I hope I am not asking something that has been answered
before. Anyway...

The top value of a DIV is affected by the following
conditions:

* child of relatively positioned BODY (not static, not absolute)
* BODY has a PRE as a child
* DIV appears as a child of BODY before any other text node or any other
element having border, height or width.
* no border on BODY

Noticed in these browsers:
IE8, Chrome 2, Safari 4, Firefox 3.5, Seamonkey 1.1, Opera 10.

The result is that the testNode DIV is offset by the font size of the
PRE element.

http://dhtmlkitchen.com/ape/adhoctest/css/bodynows.html

#testNode is, from viewport edge, flush left and offset from the top by
the PRE's font size.

I expected #testNode to be at 0, 0.

Why do the browsers position #testNode from the top, based on the
font-size of the PRE element?

It looks like Firefox (and Opera) are setting top and bottom margins of
about 1em on pre in the default stylesheet, which is a reasonable thing
to do.

The top margin collapses with BODY's top margin moving the top edge of
BODY down. The bigger the font-size, the bigger an em is, so the bigger
those margins.

If BODY has a border, the margins don't collapse. If it's position:
static, then the container for the positioned thing is the viewport, not
BODY, so BODY's margins don't matter.

Set margin: 0 on the PRE and that will solve the problem.

Adding a text node in BODY or a div with height before #testNode will
also cause testNode to be at 0,0.

The important thing is that that text node is between BODY and the PRE,
which also prevents their margins collapsing.

Why is #testNode's top offset by the PRE's fontSize when BODY has
position: relative?

The top edge of BODY moves down because its top margin collapses with
the top margin of its first normal flow child (the PRE).

Why does adding a border to BODY change that?

A box's top margin only collapses with the top margin of its child if it
doesn't have a border. It's all in 8.3.1 of the CSS 2.1 spec (and is the
second hardest thing to understand in CSS).

Ben C wrote:

On 2009-09-19, Garrett Smith <dhtmlkitchen (AT) gmail (DOT) com> wrote:
I noticed something that does not make sense to me. I do not read this
NG regularly, so I hope I am not asking something that has been answered
before. Anyway...

The top value of a DIV is affected by the following
conditions:

[snip]

Why do the browsers position #testNode from the top, based on the
font-size of the PRE element?

It looks like Firefox (and Opera) are setting top and bottom margins of
about 1em on pre in the default stylesheet, which is a reasonable thing
to do.

And Chrome and probably IE8 and possibly others.

[snip]

A box's top margin only collapses with the top margin of its child if it
doesn't have a border. It's all in 8.3.1 of the CSS 2.1 spec (and is the
second hardest thing to understand in CSS).

Thank you for clearing up my confusion with the detailed explanation.

But what is the #1 hardest thing to understand in CSS?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

In article <slrnhbbp85.33j.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

Why does adding a border to BODY change that?

A box's top margin only collapses with the top margin of its child if it
doesn't have a border. It's all in 8.3.1 of the CSS 2.1 spec (and is the
second hardest thing to understand in CSS).

Just a small note on this for now. I have noticed that a non-zero
padding on a parent can also make the top margin of a child spring to
life.

<http://dorayme.netweaver.com.au/alt/absolutely_one.html>

--
dorayme

In article <h98v2s$uer$1 (AT) news (DOT) eternal-september.org>,
Garrett Smith <dhtmlkitchen (AT) gmail (DOT) com> wrote:

Ben C wrote:
On 2009-09-19, Garrett Smith <dhtmlkitchen (AT) gmail (DOT) com> wrote:
I noticed something that does not make sense to me. I do not read this
NG regularly, so I hope I am not asking something that has been answered
before. Anyway...

The top value of a DIV is affected by the following
conditions:


[snip]

Why do the browsers position #testNode from the top, based on the
font-size of the PRE element?

It looks like Firefox (and Opera) are setting top and bottom margins of
about 1em on pre in the default stylesheet, which is a reasonable thing
to do.


And Chrome and probably IE8 and possibly others.

[snip]

A box's top margin only collapses with the top margin of its child if it
doesn't have a border. It's all in 8.3.1 of the CSS 2.1 spec (and is the
second hardest thing to understand in CSS).

Thank you for clearing up my confusion with the detailed explanation.

But what is the #1 hardest thing to understand in CSS?

Perhaps things to do with vertical alignment. Or it is second hardest
for similar reasons that students are rarely given 100% for any effort.

Actually, I was making a few new examples for you in answer to your
initial inquiry which was interesting because it involved some quite
counter-intuitive things but I have not quite finished. You can take a
peek at a page I made age ago that deals with an aspect of collapsing
margins.

<http://dorayme.netweaver.com.au/alt/shroyer.html>

and these are works in progress, sure to change. But some people might
find some things informative or at least food for thought.

<http://dorayme.netweaver.com.au/alt/absolutely_one.html>
<http://dorayme.netweaver.com.au/alt/absolutely_two.html>

--
dorayme

On 2009-09-21, Garrett Smith <dhtmlkitchen (AT) gmail (DOT) com> wrote:

Ben C wrote:
On 2009-09-19, Garrett Smith <dhtmlkitchen (AT) gmail (DOT) com> wrote:
I noticed something that does not make sense to me. I do not read this
NG regularly, so I hope I am not asking something that has been answered
before. Anyway...

The top value of a DIV is affected by the following
conditions:


[snip]

Why do the browsers position #testNode from the top, based on the
font-size of the PRE element?

It looks like Firefox (and Opera) are setting top and bottom margins of
about 1em on pre in the default stylesheet, which is a reasonable thing
to do.


And Chrome and probably IE8 and possibly others.

Probably-- I didn't test in those.

[snip]

A box's top margin only collapses with the top margin of its child if it
doesn't have a border. It's all in 8.3.1 of the CSS 2.1 spec (and is the
second hardest thing to understand in CSS).

Thank you for clearing up my confusion with the detailed explanation.

But what is the #1 hardest thing to understand in CSS?

Vertical alignment of inline boxes (along with line box height and all
that stuff). It's also very difficult to see much use for it beyond
super and subscript (which are better done with relative positioning
anyway, since that doesn't affect the line box height).

On 2009-09-22, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <slrnhbbp85.33j.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

Why does adding a border to BODY change that?

A box's top margin only collapses with the top margin of its child if it
doesn't have a border. It's all in 8.3.1 of the CSS 2.1 spec (and is the
second hardest thing to understand in CSS).

Just a small note on this for now. I have noticed that a non-zero
padding on a parent can also make the top margin of a child spring to
life.

http://dorayme.netweaver.com.au/alt/absolutely_one.html

Yup, that's right, padding does it too. I sometimes suggest setting 1px
top padding as the easiest way to prevent unwanted margin collapsing.