Sorry for the delay in getting back to you on this… Busy weekend. I’m going to cover a lot more than the menu.
Here’s a demo of what I mean:
Vision 1 Desktop
as with all my examples the directory:
Index of /for_others/cluongo
is unlocked for easy access to what I did. I re-saved the logo image at 5% loss to get the filesize under control, cut the tiled background down to a normal size for the menu, and added a hover state to the menu image as the bottom half of it.
As you can see, the HTML doesn’t need many of those extra wrappers, and does things a bit differently. It starts out with a MODERN doctype instead of being stuck in 1998… includes media types appropriate to this styling so we’re not sending this to print or other devices where it might not make sense… You’ll also notice closing comments – adding closing comments makes it clear what’s being closed, I use # and . to say class or ID just like you would in CSS there. I don’t say “close” because that’s what </div> means, I don’t say it on semantic tags since, well… they’re tags that have meanings. I put the comment BEFORE the closing tag because there’s some odd bugs with comments in most every version of IE and some minor point releases of FF that can cause extra block-level containers to be thrown in the DOM (FF) or worse, can cause the content to fail to render or even render twice (IE).
but the real changes come in it’s guts.
<h1>
Vision 1 Desktop<br />
<small>Desktops / Laptops / Repair</small>
<span><!-- image replacement --></span>
</h1>
That image is a presentational affectation of some text, as such it really has no business in the markup. It’s also the first heading on the page of which all other headings should be treated as subsections – that’s H1’s job. By adding text and using the small-tag to de-emphasize the tagline we give search engines and screen readers something to look at – and we can apply styling for the people who browse with images disabled and CSS on. The empty span we can then position over that text to apply the image. Since there should only ever be one H1 on a page, we don’t need any classes or ID’s or extra wrapping DIV.
The menu:
<ul id="mainMenu">
<li><a href="#">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Products</a></li>
<li><a href="#">Support</a></li>
<li><a href="#">Contact</a></li>
</ul>
Gets the id directly on it. UL is a perfectly good block level container so there is no reason to be putting an extra DIV around it. That’s just a waste of code – even if it is so common a practice they came up with some shtickdrek excuse to justify doing so with the completely useless “nav” tag in HTML 5…
You’ll also notice I threw in some HR – I use those to break up sections for people who browse with CSS disabled. I set them to display:none globally – you want to use them in the content, turn 'em back on.
On the CSS side, I start out with a reset so I don’t even have to think about the oddball and different margins/paddings/borders on elements across browsers. there are bigger ones, they tend to defeat the point of using CSS and are a waste of bandwidth. There are smaller ones, they tend to break form elements. There are people who say “don’t get in the habit of using resets” – it usually takes them days to do what I do in five minutes.
On body I set text-align:center first so IE 5.x will center #pagewrapper… I know, IE5.x who cares? how about all the people with windows mobile phones more than two years old? That’s right, until two or so years ago the most recent IE for win mobile was 5.5, and they JUST got 6.x at that time. (and we wonder why Opera on mobile is so popular). It’s one extra line that if we take care, means we can support all the way back to IE 5 with little to no extra effort than it takes for 6, 7 or 8. (see why I think IE conditionals for CSS is BULL… Javascript, working around the **** implementation of OBJECT, sure. CSS, not so much)
From there I set up the font I’ll want across most of the page – I advise against trusting the default font, I advise against using a serif font on screen. Serif good print… not good screen. Mongo like screen… You’ll notice I set both the size (85%) and the line-height (140%)… the first of those gives us 12px for 75dpi users, 14px for 96dpi users and 17px for large font/120dpi users – which for arial and helvetica seems to be the idea. You use other fonts, you’ll want to play with that.
The h1 gets position relative and width:100% to trip haslayout – this lets us position that child span appropriately in relation to it. I do a text-transform to make it match the styling and give it some pretty colors for images off users.
The height of the H1 is calculated using padding and line-height rather than explicitly stating it. As a rule of thumb I try to avoid saying heights on any container with text in it… they tend to break otherwise. The small tag inside the h1 gets display:block so that it’s line-height only equals what’s declared inside it. Failing to do so will space it out to the 48px used on the h1.
39px top padding + 48px line height + 24px line-height +39px bottom padding == 150px – the height of the image being placed over it.
The span is again where I applied the heading image. It’s just absolute positioned over it with the logo image centered inside it.
#mainMenu I strip bullets off of, and set a px metric font. PX for fonts is generally an accessibility /FAIL/ on content – it’s why the WCAG says “DON’T DO THAT!!!” – but when you want to interact with a background image you aren’t left a whole lot of options in that department. When forced to do so by a image interaction I recommend 12px as the smallest you should EVER consider, and then do all-caps… 14px is a little…twictchy, but it’s very unlikely even large font/120dpi users will ***** about 16px bold text being “too small”… We also set a background color here for images off users, and tile the background image.
#mainMenu li – this I just strip formatting by setting to inline. As a rule trying to style LI cross browser is a pain in the ass, and should be avoided unless you REALLY need to make a dropdown menu out of them.
#mainMenu a – inline-block on these lets us add top/bottom padding. Since on #mainMenu I made it 18px line-height, 9px top and bottom padding gives us 36px total height, whcih I changed your background image to. As a rule of thumb, try to use multiples of 4 for heights and 8’s for widths, as they tend to compress better when saving as .png or .jpg.
Oh, also note I made the background image a .png since it only consumes 234 bytes that way, instead of the 16k jpeg you had there.
#mainMenu a:psuedos – for the hover/keyboard states I just set the background color darker for images off users, then slide the background position up. This reveals the bottom half of the image file allowing you a graphics appearance when hovering those buttons without using a separate image file. More files == more handshakes to the server which means slower page loads.
The rest of it I just tossed some styling on as examples. Notice I pad the top of the content area, but the bottom of the P tag. I do this instead of using margins so as to avoid any margin collapse headaches once floats are involved.
Hope this helps.