Closed Bug 1224292 Opened 9 years ago Closed 9 years ago

Empty Div (Hidden or Visible) Immediately After the Body Tag Pushing Body Down

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Version:
42 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: earnolmartin, Unassigned)

Details

Attachments

(1 file)

firefox_empty_div_bug.zip
93.63 KB, application/zip
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.7) Gecko/20151012 Firefox/31.9 PaleMoon/25.7.3
Build ID: 20151012153601

Steps to reproduce:

If a hidden empty or empty div follows immediately after the body tag in an HTML document, the body is pushed down for no apparent reason.  Other browsers do not do this.  IE 11 and the latest version of Chrome do not experience this incorrect behavior.  

Attached is an HTML sample showing the body tag being pushed away from the top of the html element for no reason.  The pink background color is the html element, and the body has the black background color.  The html element should not be seeable, as the body is taking up 100% width and height.


Actual results:

Body is incorrectly being pushed down away from html element.


Expected results:

Empty divs and empty hidden divs should not affect the body.
Component: Untriaged → Layout: Block and Inline
Product: Firefox → Core
Eric, thank you for the bug report.

Per the CSS spec, the paragraph should in fact "push the body down", due to margin collapsing, which gives the body a nonzero top margin (because the top margin of the <p> collapses through the empty thing above it and with the top margin of the <body>).  You can see this in all browsers, including Chrome and IE, if you put your document in standards mode by putting <!DOCTYPE html> at the beginning of it.  So that's the starting basis: the "pushing the body down" behavior is the _correct_ behavior in this situation, per the CSS specification.

Now without the doctype declaration, the document is in quirks mode.  In quirks mode, Firefox will set the top margin of the first element child of body to 0 as a workaround for sites that were created before CSS existed and don't expect margin collapsing to occur.  So if your markup is:

  <body>
    <p>Some text</p>
  </body>

then in quirks mode the top margin of the <p> is 0 and there is no top margin on the body.

In your testcase, though, the markup is:

  <body>
    <div></div>
    <p>Some text</p>
  </body>

so the quirk doesn't apply, since the <p> is no longer the first child of the <body>.  It therefore still has a nonzero margin and you get the behavior you see.

The quirks mode behavior is specified at <https://html.spec.whatwg.org/multipage/rendering.html#margin-collapsing-quirks> and as far as I can tell is exactly what we implement in this case: the top margin of the <p> in your testcase is not getting set to 0 because it has as "substantial" previous sibling: the <div>.

Marking invalid, since we're exactly following the specs here.

Note that Chrome has a bug report (opened by one of their developers last year) on the fact that they don't match the spec here.  See https://code.google.com/p/chromium/issues/detail?id=443952
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Interesting.  If that is the case, how does one go about putting a paragraph into the DOM that doesn't push the body down?

I read this article about collapsing margins:

https://css-tricks.com/what-you-should-know-about-collapsing-margins/

When I set padding-top:1px; for the body, the paragraph no longer pushes the body down.  This doesn't seem ideal though.  A child's margins should never be able to go outside of the body or affect the body.  The body is the root of the document (under html) which is very important.  

Was the quirks link the official spec for this?  This spec needs to be changed...
> how does one go about putting a paragraph into the DOM that doesn't push the body down?

That depends on the structure of the DOM, but most simply, give you paragraphs a 0 top margin.

> A child's margins should never be able to go outside of the body or affect the body. 

A child's margins explicitly collapse with those of the parent.  See http://www.w3.org/TR/CSS21/box.html#collapsing-margins

> The body is the root of the document (under html)

Except that it's not used as the positioning parent for absolutely or fixed positioned things.  And floats can float out of it.  That's off the top of my head; I expect there are other things that make it not be the root in any meaningful way.

> Was the quirks link the official spec for this? 

The official spec is a combination of http://www.w3.org/TR/CSS21/box.html#collapsing-margins and https://html.spec.whatwg.org/multipage/rendering.html#margin-collapsing-quirks and the default styles for <p> which give it a top and bottom margin (specified at https://html.spec.whatwg.org/multipage/rendering.html#flow-content-3 second rule in that block of CSS).

> This spec needs to be changed...

I don't see why, honestly.  We're talking about a behavior that is (1) quirks-only (2) only visible if you set backgrounds on both <body> and <html>.  The set of pages that fulfill both criteria is tiny, even before you get to worrying about what the behavior should be exactly.
It's not quirks-only though.  When I add the doctype declaration, I still think the behavior is wrong.  I want the default margin styling of paragraphs without having to override it.  However, I now have to override the default style for the first paragraph in the body so that it has no top-margin?  That way it doesn't run into the body and push it down?  That seems odd.

Also, it is visible without setting a background color on the HTML element.  This was only done to further illustrate this behavior.  I would like to set the entire body background color to be a certain color, but if the collapsing margins issue with the paragraph happens, then you see this weird space that is not colored which makes your page look bad.  I suppose you could set the background color on the HTML element, but I don't normally have to set any styling on the HTML root element.

I appreciate your responses to this.  I am confused.
> When I add the doctype declaration, I still think the behavior is wrong.

OK, but now you're talking about changing every single browser and 15+ year old specifications.  I understand where you're coming from, and I happen to think that collapsing between children and parents was a mistake in CSS all those years ago, but at this point there's a lot of content depending on that behavior, so I very much doubt it can change.

> but if the collapsing margins issue with the paragraph happens, then you see this weird
> space that is not colored

That only happens if you have also set a background on the <html> element.  Otherwise the <body> background is propagated to the viewport, not painted on the <body> box itself.

Simple testcase:

  data:text/html,<body style="background: green"><div></div><p>some text</p>

Note that the whole viewport is green...
Ah, thanks.  That clears it up.  This is why I haven't seen the behavior before.  I made the mistake of giving the html element a background color.  I've never done that before by accident.  Thanks!  Wow.

Nothing to see here... ;)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: