Quirky Margins Across Browsers Shouldn't Be Happening

HTML & CSS
1

I understand margin issues between Internet Explorer and other browsers, and I thought I managed to elude them in my design. Problem is not with IE, though, it is with Firefox.

Can anyone tell me what I’ve done wrong to make this page look so different across browsers:

http://www.technologistsinc.com/navtest/test.php

This page doesn’t even look the same between Firefox for Mac & FF for PC! HINT: FF 4 Mac is the way I want it to look…

I really do not want to resort to creating a sniffer for every frikken browser on earth, and I shouldn’t have to. I am convinced that some sort of sloppy CSS programming is to blame. Can anyone point out my error? I’d sure appreciate the education.

2

Hi,

Can you point me to the areas that you are seeing problems in?

I had a quick look and the only browser that looked immediately wrong was IE7 when hovering the links.

I am probably looking in the wrong place or missing the obvious.

3

That is exactly the problem: the hovering links are supposed to mesh seamlessly with the background image. When you hover over the link, it turns the same color as the stripe below it (eventually, I will have a submenu that pops in and out via jQuery. I will also script it so that when you land on one of the other sections, the background of that section will highlight.)

However, in Safari, Opera & Chrome (on Mac–haven’t verified on PC yet, though an earlier version showed the same quirkiness there too,) the hover-over color does not extend all the way to the stripe (or sometimes extends too far, with the white side borders poking through.) Why is it doing this, and not sitting pretty like I want it to?

4

Hi,

The problem is that you have a fixed height to play with yet you have not set a fixed height for the anchor. You have used top and bottom padding which will assume that all browsers render text the same and this is not true especially on the mac system.

Set the height and then they will all behave the same.

The problem in IE7 is that you run an inline element into a block level element thus incurring a whitespace bug. It’s bad practice to butt inline elements against block level elements especially when you want pixel perfection.

Wrap a block level element around your logo and set the height of the anchor as follows:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Untitled Document</title>
<style type="text/css">
body {
    font: 100&#37; Verdana, Arial, Helvetica, sans-serif;
    background: #fff;
    margin: 0px;
    padding: 0px;
    text-align: center;
    color: #000000;
}
.homeColFixCtrHdr #container {
    width: 720px;
    margin: 24px auto 0;
    text-align: left;
}
/* Menu Working */
#menu {
    position:relative;
    height:144px;
    background: url(http://www.technologistsinc.com/images/subPages_Img_Slice_4TEST_01.gif) no-repeat center 24px;
}
[B]#menu p{margin:0}[/B]
#menu .topLogo {
    margin: 0px;
    border-style: none;
}
#menu div.nav {
    margin: 14px 0px 0px;
    padding: 0px;
    text-align: center;
}
#menu div.nav h2 {
    font: normal 10px Arial, Helvetica, sans-serif;
    text-transform: uppercase;
    margin: 0px;
    padding: 0px;
    width: 100px;
    float: left;
    height: 48px;
}
#menu div.nav h2 a {
    display:block;
    color: #FFF;
    text-decoration: none;
    margin: 0px;
  [B]  padding: 9px 0px 0;
    height:33px;[/B]
    text-shadow: #214666 1px 1px 1px;
    border-top: none;
    border-right: 1px solid #FFF;
    border-bottom: none;
    border-left: none;
}
#menu div.nav h2 a:hover {
    background: #d5632a;
    text-shadow: #214666 1px 1px 1px;
}
#menu div.nav ul {
    width: 100%;
    position: absolute;
    top: 116px;
    left: -20%;
    right:80%;
    height: 60px;
    margin: 0px;
    padding: 0px;
}
#menu div.nav ul li {
    display: inline;
    list-style: none;
}
#menu div.nav ul li a {
    font: normal 12px Arial, Helvetica, sans-serif;
    color: #FFF;
    text-decoration: none;
    margin: 0px;
    padding: 0px 12px;
    text-shadow: #214666 1px 1px 1px;
}
#menu div.nav ul li a:hover {
    color: #000;
    text-shadow:none;
}
#menu div.nav ul li a.here {
    color: #000;
    text-shadow:none;
}
.hovering {
    background-color: #d5632a;
    text-shadow: #214666 1px 1px 1px;
}
#menu div.nav h2 a.here {
    background-color: #d5632a;
    text-shadow: #214666 1px 1px 1px;
}
.show {
    visibility:visible;
}
.hide {
    visibility:hidden;
}
</style>
</head>
<body class="homeColFixCtrHdr">
<div id="container">
    <div id="menu">
      [B]  <p><a href="index.php"><img class="topLogo" src="http://www.technologistsinc.com/images/final-Logo-tagline-2010.gif" width="295" height="60" alt="company logo" /></a></p>[/B]
        <div id="about" class="nav">
            <h2><a href="about_ti/index.php">About</a></h2>
        </div>
        <div id="govt" class="nav">
            <h2><a href="government/index.php">Government &amp; Military</a></h2>
        </div>
        <div id="postcon" class="nav">
            <h2><a href="postconflict/index.php">Post Conflict/ Post Disaster</a></h2>
        </div>
        <div id="infra" class="nav">
            <h2><a href="infrastucture/index.php">Infrastructure Development</a></h2>
        </div>
        <div id="prod" class="nav">
            <h2><a href="production/index.php">Production &amp; Manufacturing</a></h2>
        </div>
    </div>
</div>
</body>
</html>

That looks the same to me on PC/mac FF3/safari4 and IE7/8.

Hope that helps :slight_smile:

5

Yes!

This makes absolute sense to me–and it does work in this iteration. The reason I need to butt all these inline elements against block elements is for the navigation, which will be jQuery-driven. I will proceed with that and get back to you if I run into any more problems (which I do believe I will…)

I am interested in keeping this semantic–which may be why I am experiencing such aggravation. There will be an unordered list that follows each H2 tag, that jQuery will make appear & disappear (I know, a whole other topic.) But I am concerned that I have to wrap the logo in a P tag – why can’t I just declare:

#menu .topLogo {
margin: 0px;
border-style: none;
display:block;
}

?

6

But I am concerned that I have to wrap the logo in a P tag – why can’t I just declare:

Well try it and see if it still kills the bug in iE7. :slight_smile:

It may well do the job without the need for the extra element but the semantics still remain the same as I said before.

What happens is that the browser must create an anonymous block box on the fly to make up for the one that is missing and although this is perfectly valid as you already have it it requires IE to have to think and do something extra and hence the bug appearing.

To be honest I always try and keep everything on the correct level and never run inline elements into block elements except in one case.:slight_smile:

I go against my own guide lines when I do drop downs.


    <ul>
        <li>[B]<a href="#"></a>[/B]
            <ul>
                <li><a href="#">Sub</a></li>
            </ul>
        </li>
    </ul>

Usually this doesn’t cause problems because the nested ul is usually absolutely placed and whitespace isn’t an issue. I still feel its wrong but the alternative would mean adding and styling all the extra elements.

Although to me the above structure is the same as saying:


<div>
hello
<p>some more text</p>
</div>

Perfectly valid but semantically incorrect :slight_smile:

7

Thank you so much for helping me through this. I am afraid that I am having trouble following you, and furthermore worry that you might have exposed a huge hole in my education.

I am beginning to see why most navigation schemes are vertical instead of horizontal-- then you don’t have to worry so much about margin differences, and you can make practically everything display as block. However, my boss is in love with horizontal navigation schemes (look at the previous one at the root.) This scheme works like this:

<h2><a href=“#”>About</a></h2>
<ul>
<li><a href=“#”>Contact</a></li>
<li><a href=“#”>News</a></li>
<li><a href=“#”>Careers</a></li>
</ul>
(repeat for each section)

Necessarily, not only do the headers need to be displayed inline, but all the lists need to be inline below the collection of headers! Since I really haven’t been able to locate any best practices for this sort of thing, I’ve had to invent it as I went along.

This is all going to get academic after this point:

I for one abhor absolute positioning. I tried using it here, but when the browser resized, the elements stayed in their x/y position, which completely broke the layout. Percentages don’t help-- they just make the math more complicated and the layout more unreliable.

I always thought that whenever you declared a height to any element, you also automatically HAD TO declare its positioning (i.e., absolute, relative, etc.) Subsequently, I also try to avoid height declarations unless unavoidably necessary.

I am currently reviewing the W3C documentation on the Visual Formatting Model. But if you can direct me to any other resources to fill in this hole in my understanding, I’d sure appreciate it!

(BTW, this all does seem to be working well now on the staging server–which I must keep behind a login wall.)

8

D’oh!

I think I just got it! You cannot MIX block and inline elements within a block element! Right? If you do, the browser automatically creates its own block element for the dangling inline element… am I on the right track?

9

Yes you’ve got it :slight_smile:

It’s valid either way and therefore you could argue that nothing is wrong. It’s just the semantics of it and the fact that it will occasionally trip browsers up.

10

You don’t need to declare positioning just because you provided dimensions but as you quite rightly say most of the time you would avoid putting height on fluid content.

However, when you have a fixed height that you need to fill then you need to supply a dimension because you can’t assume that the element plus its padding plus its content will fit exactly. In those cases you would need to set a height and to cater for text-resize it would be better in ems of course but not always feasible.

Most times the elements content could dictate its height and as long as you had no set heights that you were trying to match then this wouldn’t be an issue as slight variations would be go un-noticed.

The section on anonymous boxes is explained here.