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?
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.
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
heightis 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 :)
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.
I had the same problem when upgrading a XHTML4 website to HTML5. I had lots of these:
<a><img></a>
Which ended up with the magical extra padding around the images. For me the solution was simple -- add this css:
img { vertical-align: top; }
I've never used display: inline-block due to the IE7 issues, so I'm not familiar with its quirks. It seems like it's unnecessary to apply it to ul#pagetab in your situation, since it's not surrounded by inline elements. I would just convert it to a regular block element. Moreover, since it contains floated elements that do not need float beside some inline elements, I would just give ul#pagetab a real height via display: block; overflow: hidden;.
This appears to resolve all your issues (which I can't account for in detail) and provides stylistically more appropriate styles.
Mate you have 2 stray </div> tags in that page. On lines 32 and 34. Delete and retry. See if that fixes it.
wow. @matt is right (not in this case) and that's general knowledge, but you're all wrong.
dude look @ your css, you have
for .....
so that second declaration is on nested ul that occur in #pagetab. you dont have any of those.
i took the ul off the declaration so they're on the correct element. now your css has 2 styles that match for both (and are also called in your universal selector (fyi, which goes above your body{} declaration)) so thats 3 styles....overkill dude. moreover, the ones not matching, you set it to display:inline-block and then reset it to block...i'm lost in this logic.
SO take your example. change two pagetab styles to this
background-color: #ff2d00;
padding: 0px 4px;
margin: 0;
}
list-style: none;
margin: 0px;
padding: 0px 4px;
display: block;
}
save it. now strip off it, save that as #2. in FF3.6 on 7 they are the same.
if you would use the validators that are provided specifically for solving/preventing issues like this, as well as qa tools (specifically here i'm talking about the dust-me selectors bookmarklet) you would resolved this in not time.
back to web standards, gen ed css: *{} is universal, so as long as another declaration doesn't override *'s specificity, it will always work. in english, if you declare *{margin:0; padding:0; border:none} at the top of your page, you don't have to put margin:0; padding:0; on every single element. you already have.
web standards, they'll save your life.
element.
– Dakota Oct 15 '10 at 23:08