Extra Padding/Spacing

I’ve made a jumbled mess, so I stripped my html and css to just the basic structure trying to figure out what I’m doing incorrectly. Essentially the page has a “header” container at the top of the page. Below that, it is divided into two columns; on the left are navigation buttons and to the right is the content.

The only fixed width is for the navigation buttons. I’m not after a “pixel-perfect” look, but I’m getting a gap below the header division as soon as I add any content into the top division. (I changed the background colors to emphasize the problem.)

Here it is with no content in the top division:

If I add a non-breaking space to the top division, I get this:

If I add paragraph text, the vertical buttons get “pushed down”:

<body>
<div id="container">

<div id="header" class="clear">
<p>&nbsp;</p>
</div>

<!-- Vertical Menu -->
<div id="nav" class="clear">
<nav>
<ul id="vertical">
<li><a href="#" title="">Menu Item</a></li>
<li><a href="#" title="">Menu Item</a></li>
<li><a href="#" title="">Menu Item</a></li>
<li><a href="#" title="">Menu Item</a></li>
</ul>
</nav>
</div>

<div id="content" class="clear">
<p>Lorem ipsum dolor sit etc.etc.etc...

</div></div>
</body></html>


body, html {
margin: 0;
padding: 0;
font-family: Verdana, Helvetica, Arial, sans-serif;
background-color: #292929;
}

p {
margin: 0;
padding: 0;
}
#container {
width: 100%;
margin: 0;
background-image: url(../images/menu.jpg);
background-repeat: repeat-y; 
}

#header {
width: 100%;
margin: 0;
color: #ffffff;
background-color: #ff0000;
}

#nav {
float: left;
width: 200px;
margin-top: 0;
font: 18px/1.5 Verdana, Helvetica, Arial, sans-serif;
overflow: hidden;
}

#content {
margin: 0 0 0 202px;
background-color: #ffffff;
}

/* ---------- Vertical Menu --------*/
ul#vertical {
margin: 0;
padding: 0;
width: 200px;
border: 1px solid #292929;
-webkit-box-shadow:0 0 5px #3c3c40;
-moz-box-shadow:0 0 5px #3c3c40;
box-shadow:0 0 5px #3c3c40;          
}
 
ul#vertical li {
list-style-type: none;
}
 
ul#vertical li a  {
border-bottom: 1px solid #292929;
display: block;
padding: 15px 30px;
color: #ffffff;
text-decoration: none;
text-shadow: 0 1px 0 #000;
-webkit-box-shadow: inset 0 1px 0px rgba(255, 255, 255, 0.2);
-moz-box-shadow: inset 0 1px 0px rgba(255, 255, 255, 0.2);
box-shadow: inset 0 1px 0px rgba(255, 255, 255, 0.2);
}

/* --- Clearfix ----*/
.clear:after {
height: 0; 
clear: both; 
font-size: 0; 
display: block; 
visibility: hidden; 
content: " ";
}

I know I have something basic, structurally wrong here but cannot figure out what to try next. Thank you for any advice.

Edited to add: Here is the actual site (in whatever frustrated mess I last left it) http://aercf.org/

I’m not really seeing the issue. Are you talking about the 10px from the image to the top of the element? That’s due to the padding on .center{}

I also threw that code you gave in a codepen and I’m not seeing it…

http://codepen.io/ryanreese09/pen/emXMYO

Regarding the first screenshot: With nothing in the top container, shouldn’t it collapse entirely?

<div id="header" class="clear">
</div>

If I add only a non-breaking space, it adds a “gap” to the right-hand container below it, as seen in the second screenshot:

<div id="header" class="clear">
&nbsp;
</div>

If I enclose the space in paragraph tags with margin, padding set to zero, it pushes the vertical menu down also as seen in the third screenshot.

<div id="header" class="clear">
<p>&nbsp;</p>
</div>

On the actual website I was using inline styles to try to eliminate this problem, overriding whatever I have in the external stylesheet. It’s not working well, in addition to defeating the purpose of an external style sheet. Additionally, whatever I’ve done is causing padding and margins (top and bottom, not horizontal) to not take effect within the content section of the pages.

On the site itself, the only page where the problem doesn’t appear (or at least it seems it’s not occurring) is on the contact page which contains a fieldset that has display set to inline-block.

I don’t know what .center{} is?

What exactly is the problem you are trying to solve? Do you have a picture of the desired result?

Well, no… I don’t have any picture of the desired result. If I had, I wouldn’t need to impose on you all to ask my question.

My desired result is a page that has a section at the top of the screen that extends the full width of the viewport. Below that I would like it split into 2 columns. To the left, would be some menu buttons arranged vertically; to the right I would like an area wherein I can arrange content. That’s all; it should be simple, but I’m doing something wrong.

Right now, I don’t know if it’s a browser thing; but I suspect not because I’ve tried it across various browsers. So it’s got to be me. Somehow I don’t have my basic structure set up correctly. I’ve spent hours on this and just can’t figure it out, so was hoping someone could give me a hint/clue on what I’m doing wrong. So far I’ve been piling “broken” upon “broken” and that’s not a good solution. …in my opinion.

Edited to Add: One additional result I’d like is that my top container doesn’t “jump around” with random spacing on the top/bottom margins/padding (not horizontal; that works.) I’ve tried various combinations of display and position.

Pesky escaping margins.

paragraphs have vertical margins by default (one em top and bottom). These margins can escape their parent container and cause these annoying “spaces”. When you zero’d the vertical margins on the paragraphs, you cleared the current problem by removing the source of the space.

However, there may be times when one wants to preserve those margins. In those cases:
(1) Apply {overflow:hidden;} to the parent container with the paragraph. Margins become contained.
(2) Add vertical borders to the parent containers. Margins become contained.
(3) Apply an appropriate clearfix. Your clearfix only “fixes” the bottom of the parent container. It will not contain the margin of the topmost <p>. Margins become contained.
(4) Apply padding instead of margins to the topmost paragraph, if desired. Works like borders to contain the margins.
(5) Floated parent containers “contain” the margins of their immediate children.

These techniques do not behave consistently. Try them and see for yourself.

See also: http://www.sitepoint.com/community/t/relative-position-and-whitespace-at-bottom-below-footer/33785

Plus, @PaulOB has written extensively about this very common problem.

Unrelated:
Block objects, such as <div>s occupy the full width of the available space by default. As such they do NOT need to be routinely assigned a width of 100%. In fact, doing so can cause problems in some cases.

Personally, I do not recommend using IDs except where needed for JavaScript calls or links by fragment identifiers. Classes are more versatile and less problematic. In fairness, though, there are valid arguments on both sides of the class vs ID contest. :shrug:

“position” is not an issue here. It’s really just margins. Just a thing you are running into for the first time.

For testing purposes, I changed your IDs to margins and added a “cf” for clearfix to the two parents that needed it. Give the different methods a try by subsitiuting the “cf” for “clear”, etc. It’s interesting.

<div class="container">
    <div class="header cf">
        <p>&nbsp;</p>
    </div>
<!-- Vertical Menu -->
    <div class="nav">
        <nav>
            <ul class="vertical">
                <li><a href="#" title="">Menu Item</a></li>
                <li><a href="#" title="">Menu Item</a></li>
                <li><a href="#" title="">Menu Item</a></li>
                <li><a href="#" title="">Menu Item</a></li>
            </ul>
        </nav>
    </div>
    <div class="content cf">
        <p>Lorem ipsum dolor sit etc.etc.etc...</p>
    </div>
</div>
.cf:before,
.cf:after {
    content:"";
    display:table;
    line-height:0;
}
.cf:after {
    clear:both;
}

Technically (and I hate to nitpick) but they are called collapsing margins, not escaping. Sorry :frowning: . (This will allow the user to search more on this subject if he knows the correct terms.)

Thank you for the feedback.

You have my heartfelt thanks. I was really trying to figure this out on my own, hated to ask here, but was really stumped. So thank you! I will read some more because I kind of understand it but kind of don’t.

Unrelated:
Block objects, such as

s occupy the full width of the available space by default. As such they do NOT need to be routinely assigned a width of 100%. In fact, doing so can cause problems in some cases.

Personally, I do not recommend using IDs except where needed for JavaScript calls or links by fragment identifiers. Classes are more versatile and less problematic. In fairness, though, there are valid arguments on both sides of the class vs ID contest. :shrug:

The width business is already causing a problem and I’m still working on that.
Also, I had read the various pros/cons of classes vs ids. Lots of opinions out there. I’ve been trying to clean some of that up also (without breaking things.)

Thanks again.

Blocks are greedy. They want as much width as possible. They will go until they are told to stop…

Let’s say I have a parent element which is 1000px wide. Then I put a block element inside of it like a <p>. That <p> will go 1000px unless I say otherwise. The issues that can arise is if you set other stuff like padding (or margins). Let’s say you set that paragraph tag to 5px left and right padding. Without a width set, it will still be 1000px, although 10px total (left and right) will be set aside for padding.

If you set 100% width, it would be (100%+10px) which would overflow. That is most likely what Ron meant by issues arising.

In Javascript, it’s much easier to call elements by: document.getElementById(‘idhere’); than it is to use document.getElementsByClassName(‘classhere’); because that returns a nodelist and targeting the right element you want is tricky…in general it’s easier and better to use IDs where you can.

I hope that helps.

You’re very welcome.

Ryan’s explanation and example of an “issue” that could arise when a width of 100% is applied inappropriately was right on target.

I will be glad to clarify anything that I’ve written (sometimes it does leave a bit to be desired ). Width issues, class vs ID issues… let us know. .

My response here is totally off-topic…

I believe I understand the block model. In and of itself it makes sense. Then you throw in floats, which toodle around outside the flow. And quite frankly, floats are kicking my be-hind. I had a couple widths set to 100% because I was trying to “fix” an issue with a form/frameset; I threw in a couple here and there and totally forgot where. I am most appreciative that ronpat pointed it out to me; ( I took the widths out and their removal had no effect.) The form page is not where I want it to be yet, but such “oh-by-the-way” mentions really do help me to neaten up my style sheet.

Regarding class/ID selectors: I have read many differing opinions. Depending where you read, in some cases I am an evil human being based on my choices. After sifting through what I read, I was left with the impression that if you use it once, go with class and if more than once use ID, as long as you bear in mind specificity (I hate that word; I like to think of it as the order of operations.)

You’ve got that backwards :wink:

Hi, AngC,

See if this helps with the ID vs Class dilemma: (another opinion: )
http://www.sitepoint.com/community/t/my-two-button-classes-are-clashing-and-i-dont-know-how-to-fix-it/44002/12

Honestly it does not matter.

IDs are unique to a page. Only one footer? Sure, use #footer. Only one navigation? SUre, use #nav. Highlighting something on the page? Yeah, that could repeat (even if it isn’t yet.) Use .highlight.

Think about your page. Do you ever envision it even being possible to repeat that element on the page? Do you plan on using Javascript for a particular section (if so you might want to see if you can use ID.)

Ultimately it is up to you and it really does not matter the way you go. You will eventually learn a good way for you.

You’ve got that backwards :wink:

oops

I wonder whether there might be some potential “power” inherent with the ID vs class issue. Perhaps one could leverage it to do something (…beats me what; I’m still a novice.) But I’m open to the idea. Also, I have read here on the forums where someone makes a suggestion to the original poster, and they blithely ignore all they hear/read. So if someone that knows more than I do, proffers a suggestion I’m more than willing to listen. For now, I’m not going to tinker with my classes/IDs yet. I would probably break the whole darn mess. :smirk:

@PaulOB or @RyanReese among others would know more than I

eg. if I had an element
<div id="uno" class="dos">
and my CSS was

#uno { color: #f00; }
.dos { color: #0ff; }

AFAIK the subsequent class rule would not over-ride the preceding id rule

but something like

#uno { color: #f00; }
div.dos { color: #0ff; }

would.

*hint → specificity

Not sure what you’re getting at.

I agree with you that if you have a page or site of any size I wouldn’t recommend changing IDs to classes or vice versa willy-nilly. It can be tricky because the original code might have been written with the cascade and specificity in mind to reduce duplication of code… which is how I prefer to code.

Ryan is right that in the end, whatever works… works, but I disagree that it doesn’t matter. I recommend keeping an open mind and trying both techniques.

Try it!

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>template</title>
<!--

-->
    <style type="text/css">
#uno {color:#f00;}
div.dos {color:#00f;}
    </style>
</head>
<body>

<div id="uno" class="dos">This is test text</div>

</body>
</html>
1 Like