Why does the HTML5 DOCTYPE mess with my padding?

Question

I have an html5 page with a navbar. Completely scratch coded. I just recently added a doctype to the item, and now I’m getting extra space under my navbar. If I remove the doctype declaration, it goes back to normal. I have completely reset padding, margins, etc. on everything, and cut it down to the a small amount of code that illustrates the issue.

The page can be seen at http://hackthetruth.org/webdesign/broken

Does anyone know why declaring the doctype is messing with the height of a div?

Answer 1

I had the same problem with one of my sites. i found this answer here:

"With an HTML5 doctype, images receive what seems to be the line-height attribute which text normally gets, and thus you get a “margin” underneath them. You can either set them to display:block or line-height:0, although I haven’t tested the latter enough to be sure it’s a good fix."

I applied the line-height:0 to the <div> which contained the navigation images. It did the trick for me.

Answer 2

This is an interesting and subtle, yet important consideration when using inline-block.

The short answer is: set vertical-align on your ul to anything other than baseline.

The reason this works is that inline-blocks are considered text, and thus are subjected to text-based properties such as line-height and vertical-align.

---

The longer answer is as follows:

The CSS3 specification goes in to some (perhaps confusing) depth around how the box model works. Here's a quote from the CSS3 box spec, in which I've highlighted the part that's relevant to this problem:

9.5. ‘Inline-block’ or floating, non-replaced elements

... The used value of height is the computed value, unless that is ‘auto’, when the used value is defined by “‘Auto’ heights for flow roots.”

Let's check what the auto heights for flow roots are:

9.10. ‘Auto’ heights for flow roots

In certain cases (see the preceding sections), the height of an element is computed as follows:

• If it only has inline-level children, the height is the distance between the top of the topmost line box and the bottom of the bottommost line box.

...

The line box parts are of interest. What this effectively implies is that anything set to display as inline-block is subject to the implicit box layouts that plain text uses.

You might be able to guess now why setting vertical-align fixes this problem, but let's continue tracing this problem through the spec.

The line-box definition is a little lacklustre, and the example in section 4.2 is only marginally helpful.

Let's go back to the CSS 2.1 spec, which does a far nicer job at explaining line boxes:

The rectangular area that contains the boxes that form a line is called a line box ... [its height] is determined by the rules given in the section on line height calculations.

From this explanation, we see that the line-height and vertical-align properties have something to do with how the heights (of line boxes, thus inline-block elements) are calculated. Reading the calculations of line-height almost make it clear:

...In case [line boxes] are aligned 'top' or 'bottom', they must be aligned so as to minimize the line box height.

So our inline-block element's height is being affected by its implicit line box's height calculations, which are in turn subject to these vertical-alignment calculations.

So it would seem that when we don't use baseline as a vertical-align for an inline-block, the box's implicit line box will shrink to the smallest size it can.

Confusing? ...Yeah. Just jump back to the shorter answer :)

Answer 3

It's because the DOCTYPE changes the rendering mode to Standards Compliance Mode. Specifically, this means you're using the W3C Box Model now which computes width/height for block elements differently than quirks mode.

Read more here, here, and here.

Answer 4

try this one:

css:

html * { margin:0; padding:0; }