Navbar background overflow errors in Mozilla browsers

Hi

Go to http://skydive.co.za/redesign. Try it in IE7 (works as desired). Then Firefox/Chrome (bleh).

The Mozilla flavours repeat the background images on the y-axis for some (but not all) of the navbar buttons, over the navbar's bottom edge & into the div below. The navbar is a simple unordered list. All navbar buttons are 18px high, and their containing elements (li's) are set to 19px. (leaving the navbar background exposed on the last line).

The navbar layout goes #navigation > ul > li > a. The background button images are contained by the li's. If I set the #navigation's overflow to hidden, the repeated backgrounds clear, but so do the drop-down menus for the a:hover psedo classes. Code snippet:

#navigation {
	width: 100%;
	height: 19px;
}
#navigation ul {
	list-style-type: none;
	margin: 0px;
	padding: 0px;
	border: 0px;
}
#navigation ul li {
	float:left; 
	position:relative;
	height: 19px;
}
#navigation li a {
	text-decoration: none;
	display: block;
	height: 19px;
}
#navigation ul li.home {
	width: 82px;
}
#navigation ul li.home > a {
	background: url(../img/new_home.gif) no-repeat;
}
#navigation ul li.home > a:hover {
	background-image: url(../img/new_home_hover.gif);
}

Code (markup):

or go to http://skydive.co.za/redesign/navbar/css/navbar.css for the full navbar stylesheet, & view source on the main page for the content.

Any suggestions on how to get rid of the repeating backgrounds?

ANY help = MUCH appreciated.

 

It's not the repeating background, but two repeating elements.

<li class="about">
<a href="/index.asp"></a>
[B]<a href="/about-skydiving.asp"></a>[/B]
</li>


<li class="courses">
<a href="/about-skydiving.asp"></a>
[B]<a href="/jump-courses.asp"/>[/B]

<li class="bookings">
<a href="/prices.asp">	</a>
[B]<a href="#"></a>[/B]

<li class="contact">
<a href="/faq.asp"></a>
[B]<a href="#"></a>[/B]
</li>

Code (markup):

Why exactly do you have two link elements for some navigation buttons?

 

That's very odd - the original source looks nothing like what you've just posted back here???

In my source:

<li class="home">
  [B]<a href="/index.asp"/>[/B]
</li>
<li class="about">
  [B]<a href="/about-skydiving.asp"/>[/B]
</li>

Code (markup):

Very different from what you posted above? I've never know of a browser to manipulate source? Any other explanation?

 

SOLVED.
You'll have noticed from my previous posts that I was closing my anchor tags with shorthand notation. I'm not sure if this is strictly XML (I always assumed it still was), but the Mozilla browsers did not take well to the shorthand syntax.

My change, from:

<li class="courses">
  <a href="/jump-courses.asp"[B]/>[/B]
</li>

Code (markup):

to:

<li class="courses">
  <a href="/jump-courses.asp">[B]</a>[/B]
</li>

Code (markup):

did the trick - no more repeated backgrounds.

Can anyone explain my Mozilla does not interperate the normal sharthand element notation?

Thanks for the help

 

I used firebug to debug the code, I didn't check it from "view source". Yes, the "source" is exactly same as what you posted.

It isn't valid. <a> is not a singleton tag, it requires an ending tag (</a>). That's why Mozilla repeated the elements, it rendered those self-ending (slash) <a> elements as what I posted above [post #2].

 

On a further note, it would have been valid if your page were actually pure XML (it's closed). But it wasn't. It was HTML dressed up as XML (and the browser is using its HTML parser, unless you change the MIME type and I dunno what Firefox really does then). It also would have been valid as SGML. But HTML parsers never properly picked up shorttag notation correctly. We should have been able to do this
<a/text or children/
as well.

Instead, what we have to work with are buggy HTML parsers who sorta have their own standards. So currently, only elements listed as EMPTY in the dtd may have the short version of closing tags (in XHTML), such as <img/> and <br/>, while non-empty elements, even if you make them empty, can't: <div/>

My husband's boss did this once:
<a name="message" />
and actually the validator didn't say a thing. It's only checking to see that the tag is closed, after all (and what you had also "counts" as closed). Since it was empty (a destination link), no browser had the opportunity to mutilate it.

 

Thanks for the good insight all. I'm a backend developer by day, so I appreciate your patience with me. Good to be learning!