Can't get div positioning correct in IE7 - html

I can't for the live of me figure out how to get one element in my layout to be placed properly in IE 7. You can see the page here:
http://www.iancreates.com/debbie/contact/
Works fine in Firefox, but if you look in IE 7, you'll see the sidebar is beneath the body content. I've tried everything I could think of (floating both divs, changing width and margin/padding to account for IE box model) but to no avail.
Here's the relevant CSS:
.content-left {
width:670px;
height:auto;
margin:0 30px 0 10px;
padding:0;
float:left;
}
.content-right {
width:240px;
height:auto;
margin:0;
padding:0;
float:left;
}
I appreciate the help!

This is a classic IE problem, combined with a slightly impractical page layout.
You have set your peace-main div to have the width 100%, so there is no room for the right content beside it. In standards compliant browsers however, the div doesn't have any height (as it only contains floating elements), so it's not a problem that the right content ends up below it. In IE7 the div is expanded to contain it's content, i.e. the left content div, so it gets a height, and as the right content goes below it, it ends up below the left content also.
Just remove width: 100%; from the peace-main style.

Posting the CSS code would be helpful. Try using "position".

one thing you could do is set your peace-main to float 'left' and only have a width of 700px (so there is enough room for the sidebar)
then the sidebar should also have it's float set to 'right'
but i would actually suggest you try one of these methods :
http://www.thenoodleincident.com/tutorials/box_lesson/boxes.html

#Guffa's answer is correct in my estimation. I think that your page may have validation errors also that are causing it to be parsed incorrectly. Looking at your markup, it looks like you had wanted div.content-right and div.content-left to be in the same container div, however they aren't, leading the the problem as #Guffa pointed out.
alt text http://i432.photobucket.com/albums/qq48/shiftypowers/source.png
If they were in the same container however, as I think you intended, then this problem would be solved as well. Try and fix this extra div closing tag, see what that does:
alt text http://i432.photobucket.com/albums/qq48/shiftypowers/validation.jpg

Related

Why the second div moves to another line even if both of them are set to display:inline-block?

I'm a bit afraid of using floats as I didn't yet understand clearing the floats and all the hacks that are on the internet in regard to that activity so I've used display:inline-block to place two divs in inline fashion. Their container has a
width:auto;
max-width:900px;
and each of the divs has
display:inline-block;
width: 450px;
Now no matter what I do the second div always breaks to another line right below the first div.
Here's the code : http://codepen.io/anon/pen/xgtFd
I have already modified the width of the two divs like for example
width:440px;
but it didn't help. Still the second div is slightly 'off place'. That's weird cause I was making a website and using pretty much the same approach for my header like in this project. Please help me determine the problem.
I would be glad for any help.
The widths are too wide.
Bump the nav down to about 446px, and they come back in line.
Why 444px instead of 450px? Two reasons:
Your border is taking 2px.
There is whitespace between the <div> tags in your markup, which is reflected in the rendering. If you would like it to be able to make it 450px, put the closing div tag and the next opening div tag immediately adjacent, like so: </div><div id="nav">
If you want to be able to keep the border, and set the width to 450px, then you should check out box-sizing, and utilize box-sizing: border-box;.
Edit:
To address your vertical alignment issues, you need to apply vertical-align: top; to the div elements (the nav and logo divs).
And, the ul isn't centered because when you apply display:block to it, it fills the full width. So you could either make the contents of the div centered with text-align: center on the ul, or you could make the ul display: inline-block.

css table-cell, contents have unnecessary top margin

I am using table-cell arrangement of div blocks in my code. There is a problem in my code.
Preview of how my html looks is here
When I have any content (text or image) in my first panel then the .inner div of the second and third panel have a top margin of some 10-15 pixels. Why is that ?
Can any one look and let me know what I am missing.
add vertical-align:top; in #wrapper > div
See Demo: http://jsbin.com/avozik/14/edit
I have a similar case, and vertical-align:top; solves the issue. However I want to elaborate reason behind this:
https://jsfiddle.net/46tyc48y/1/
Because table cells uses vertical-align:baseline; by default, the right cell text will align to the baseline(bottom) of the image, creating the phantom spacing on the top. So we need to explicitly set vertical-align to bypass this behavior.

100% height div cutting off div inside

I am developing a website which is 100% height and width. There is a panel stuck to the left and the main content area to the right, which is scrollable.
However, in the content area the last div inside is getting cut off. I cannot see why. I have tested this on Firefox and Chrome, both are doing the same.
Here's the link to see it:
removed
As you can see, it is cut off, adding a large margin-bottom (50px +) seems to fix it, but that just looks bad.
PS: Don't worry about the missing images, it's because I've only uploaded this page, not the entire website.
Thanks in advance
Height: 100%; is fairly inconsistent across most browsers. Try to avoid it.
I'm not entirely sure how your layouts usually work, but setting overflow: hidden; on everything in your CSS reset is going to make things wonky from the start.
Take out "overflow: hidden;" and you can see the problem. Your content pane is matching the height of your body, as such, you're losing the height of "topBar" on the bottom of the page. because the Body is hiding the overflow.
Yup -- try overflow:scroll; or overflow:visible; In addition, I'd see if you can make it work without float:right;, 'cos that takes it out of the normal flow of things and can wreak havoc with your box adjustments.
ETA: I think I see the problem; each of your little content divs has floats left and right, which is gonna render margins useless, 'cos as far as the browser is concerned, each box's content is out of the normal flow of the page.
ETA(2): You have overflow:hidden; in your big first rule, where you set default styles for like a hundred different elements. That's your main problem. Change that to overflow:visible; (or whatever you prefer) and set appropriate overflow properties elsewhere and you oughta be good. I was able to mitigate the issue by doing this. There's still tweaking required, but that solves the base problem. I would still get rid of the inline floats, too.
From main-style.css line 5:
overflow:hidden
and main-style.css line 127:
overflow-y:auto
are both causing the page to cut off the bottom. However, when you correct this, it reveals that your wrapper div isn't stretching to 100% of the window height (because the background gradient stops WAY before the page ends), and the content inside your main divs go wonky. These are things that the other posters have discussed being major obstacles in your page formatting correctly.
Please take a look at this JsFiddle here. It is working in Chrome, FF, IE 6-8 and Safari.
Not sure how to fix the 100% height problem yet, but to solve the floated div content problem, make sure you declare a width of 50% on both the left and right-floated content
(also, you can make the right-floated content text-align:right in order to make it REALLY stay to the right of the div).
<div class="centerText messageWrapper">
<div class="messgaeHeader">
<div style="float:left; width:50%">
From: 12345678<br />
</div>
<div style="float:right; width:50%; text-align:right">
Date: 123456789<br />
</div>
</div>
1234567890
</div>
Perhaps someone could chime in with a fix for the 100% height issue this is causing now. I realize this isn't a complete answer, and my solution breaks the page in a different way, but perhaps it will be a jumping off point to you or someone else who may have the solution.

Overflow:hidden; retaining content width but hiding content: Chrome

These three SO questions didn't quite get me what I needed, interesting though the BFC layout stuff was. (One, Two, Three)
This fiddle shows the issue I'm having, only in Chrome is the hidden content still enforcing width dimensions of the div classed 'content' with a width value of 0px.
This layout is the basis for an Accordion style menu... which obviously isn't going to work if the enforced content dimensions are visible :P
Why is Chrome behaving this way, maybe I missed something in the BFC explanation? A solution would be awesome.
What a nasty bug!
Need to research if further, but if you know the original width of .content, then you can add the same negative margin to it: http://jsfiddle.net/kizu/cpA3V/7/ — so it would compensate the original width. And if you'll need to animate the accordion, you'll just need to animate the margin alongside the width.
Try with this
.slide {
float:left;
width:25px; /* width added here (same width of '.handle' ) */
}
Example : JSfiddle
If you give the .content a width of 1px, then it behaves correctly. I can't explain what's happening but you can solve this by using display: none instead of the width.

How to make height squeeze with css

I've got an example mht file here that will help demonstrate my issue; if you are using FF then this addon will help you view the mht file. You will prob need to download the file and view it locally since github doesn't provide the right mime type for the file.
Basically my issue is this that I have a div which is 32px in height surrounding another div which is 29px in height, and I have no idea why the former is 32px tall.. It should be 29px tall afaict.. I don't want to set height:29px tho because if you resize the window so that the nav items take two lines then the height shouldn't be 29px for either div.
So what is wrong here?
make the following changes-
(-) to make your ul and wrapper div bottoms to align change class #navigationSecondary ul.base
to have a display:table; instead of display:inline-block;
(-) to remove the 3px of blue at the bottom change class #navigationSecondary to have padding:0; as sugested by Marcel.
the use of display: inline-block; on the ul.base is the cause.
when you use that it formats an element like it were inline (it only formats the actual content of the element like a block), so ul.base will have the usual 2-3px top and bottom "padding" that a normal inline element has. It's not really padding it's the leading vertical spacing i.e. it's what gives lines enough space to provide for the ascenders and descenders of letters like g, h, p, etc.
the use of it here is to make it seem like your ul is containing the floated child list elements. To make an element contain it's floated children there are other ways to do this, one way is, on ul.base
remove: display: inline-block
add: overflow: hidden;
[UPDATED] re the tabs.. sorry I didn't see them before I started
Here's the "float everything" solution to containing child floats as it applies to your code, with some other suggestions too
.menuContainer all it needs is position:relative; and the border-right rule
.navigationSecondary float it left with a width of 100%; (you can remove z-index it's not doing anything)
.wrapper float it left with a width of 100%, remove the height
ul.base doesn't actually need anything but remove the display-inline-block.. it's not containing the child lists but there's no effect involved, if you want to you can float it left with a 100% width too
[UPDATE 2]
I just copied this to a plain HTML document and I think that just changing the DOCTYPE to an HTML4 transitional one solves the problems with no changes to the code ?? (why that should change the display be I don't quite know! - but the use of "target=_parent" is "not allowed" in Strict Doctypes so that'll be why it's not validating)
I'll put it in JSBIN so others can try it out on various browsers
I changed it to:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
jsbin (with original HTML5 doctype) is here http://jsbin.comhttp://jsbin.com/agihe5/2/ - shows gap
jsbin with changed Doctype - but no changes to CSS code - with flash video to show dropdowns are working is here : http://jsbin.com/inare6/2 - no gap!
jsbin with no changes to Doctype, suggested changes to code and the flash insert to show z-index working is here: http://jsbin.com/iriya4
with the latter, code changes are detailed in the source, they have moved to the bottom of the snapshot CSS
I've tested the changed Doctype version as working in IE7, IE8, FF3.6.15, Safari4 (Win) and Chrome
Providing a test case which requires me to use Firefox and download an extension to view it is highly annoying.
I just did it anyway (purely because of the bounty), and the only change you need to make to your test case is:
On #navigationSecondary ul.base, add vertical-align: top.
The extra height is gone.
Here's a demo based on #clairesuzy's demo titled "jsbin (with original HTML5 doctype)".
(The only change was adding the aforementioned CSS rule):
http://jsbin.com/agihe5/3
The other answers may work (I didn't test them), but (providing I've understood the issue properly), this is by far the easiest fix.
Apparently #navigationSecondary has padding:0 0 3px; set in unnamed-1.css on line 2.
Everything inside ul.base has a height of 24px. Itself has a padding of 2px. So it's height is 26px. It's parent div.wrapper has a height of 29px, 3px extra. It's not caused by the 3px padding of div#navigationSecondary. Nothing is contributing the extra 3px so I'm suspecting a float issue. Anyway I managed to fix it by floating 2 divs.
Add float: left; width: 100%; to div.wrapper and div#navigationSecondary.
Remove display: inline-block; from ul.base.
Floating div.wrapper and div#navigationSecondary collapses them to their nearest floated child element, in this case li.base, and removes the extra 3px. 100% width brings back the stretch.
Hope this helps.
<body style="zoom:0.99; -moz-transform: scale(0.99); -moz-transform-origin: 0 0;">
adjust accordingly, and change hight and width around
Of course. This is simple. A very elementary element positioning issue.
inline-block default vertical-positioning
ul.base is an inline-block. which means that it has spacing calculated like a block, but positioned like an inline-element.
The default positioning of inline-element is to align on the baseline of text. However, text goes below the baseline for letters such as g, j, q etc. This is called "descenders".
The height of a box is always from the top of the font to the bottom of the descenders.
The wrapper takes on the height of its children. Which means that the inline-block ul.base, positioned on the baseline.
Your font at that particular size happens to have a 3-pixel descender. Voila. Your mysterious 3-pixel gap is merely the text's descenders. And your inline-block element is positioned on the baseline (i.e. on top of that 3 pixels).
Tests to confirm that this is right
Change font size. You'll see that 3-pixel changes. Change font size to small enough and it'll reduce to a 1px descender. Your so-called "gap" will shrink.
Change ul.base to something other than an inline-block (of course you have to add something to clear the floats inside). It will no longer have the 3 pixels at the bottom because a non-inline element is not positioned on the baseline.
Position ul.base on the absolute bottom instead of the default (baseline). That 3-pixel gap disappears. Use this CSS rule: vertical-align:bottom
Morale of the story
You always have to be careful with baseline positioning whenever you use inline-block display style.
Off topic
Handling font descenders is especially frustrating with Asian languages. As you know, CJK languages do not have characters that go below the baseline. However, they are typically placed on the baseline (so that they can inter-mix with other European languages, which have descenders). However, when one places a block of text with a background containing only Asian characters, the text will look like it is moved to the top, with an ugly empty gap on the bottom (the descender).