Ok, on to the CSS. Follow along with
First is that reset of mine. Never needed more.
hr - I strip all horizontal rules as I usually use those just to divide up content for people browsing with CSS off. I can use border or background-images on my block level containers if I want that on the screen version of the document.
* html body - the "* html" hack targets just IE6. I try to avoid using it as much as possible, but in this case it's a necessary evil since we only want to load csshover3.htc for IE6/earlier as in our case they are the only browsers that need it. You can find out more about this file here:
body - The comment on the text-align says it all. IE5.5 is for all intents and purposes little more than IE6 permanantly stuck in 'quirks mode' since it was built to CSS2 before the standard came out of draft. (and yes, that is why we have the broken box model!). As such it ignores margin:0 auto for centering, but incorrectly obeys text-align on the parent. Next I set up the font as %/em. You were using pt, which there's nothign really wrong with (some people would disagree - I say hey, at least it obeys the system metric) but for the page content, you REALLY should be using %/em. Just remember that for large font/120dpi users, uber-large 150% Win7 users the fonts will automaticalyl enlarge while your px sized elements (like images) will NOT, and that for some handheld users everything will appear 25% or so SMALLER (72 or 75dpi instead of 96) - though most handhelds just ignore font-size alltogether... background color is nothing to write home about.
#pageWrapper - width, center it with margin, turn off the center text-align we set on body now that #pagewrapper is centered in IE 5, and I set the content background color here because I can. The h1 and #footer will overlap it anyways.
h1 - since you are only ever supposed to have one h1 on a page, we don't need any classes or id's to target it or it's children if we take proper care. Position:relative lets us absolute position that B tag sandbag in relation to the h1. I use the "holly hack" of height:1%; to trip "haslayout" - a special rendering quirk that fixes IE7/earlier positioning bugs. Percentage widths and heights are automatically changed back to "auto" if the parent element doesn't have a fixed height or width declared on them (except for html and body which are special cases) - as such that's the same as saying "height:auto" in standards compliant browsers (everything except IE)... for IE it is also treated as auto, but for some wierd reason it fixes some positioning bugs. Width, Height or zoom:1 are the most common haslayout triggers. I also set the font size for our largest text here.
The negative bottom margin needs a bit of explanation. By setting that I made it so that content after the element is 'ridden up' over our 182px tall heading. Basically it makes the page pretend that header doesn't even exist when it comse to placing other stuff on the page! It's a cool trick that often lets you avoid the headaches floats can create.
h1 a - the red color for the largest text, and strip the underlines.
h1 span - our nested span I set to display:block to force it to a new line below the big red "LIFTING" and we shrink it's size and make it black. The negative margin just rides it up a bit closer.
You are probably noticing I do NOT declare our total 182px heading height on any of these elements. 46px top margin + 64px line-height + 23px line-height - 5px negative margin + 54px bottom margin == 182px... By not declaring the height, we avoid the IE5 broken box model and skip an unneccessary line of CSS.
h1 b - and here's our logo image. I reduced it to a single file since blowing 17k on a separate logo seemed like a waste of time. Simple absolute positioning 0 0, with width and height of the image and the image as the background.
#contactInfo - Know how I said that negative margin on our h1 would make the content after appear OVER the content? That means all we have to do is make sure our right 'info' area is properly padded to total the same 182px height, so our margin falls into place. The left margin makes it so you can always click on the right half of the header to get to the home page - in some browsers if we let the entire div overlap you'd be unable to click on "h1 a". We are forced to use PX metric fonts here because of the image interaction - using %/em or pt would cause the layout to break horrible on machines that are not at the so called "default" 96dpi... LIKE MINE. 14px is usually the smallest I will go in Tahoma since that's the edge of legible for 120dpi users. (LIKE ME). Add in a text-align:right and we dodge all that pesky float nonsense.
#mainMenu - the position:relative in this case is to make sure it depth sorts over content. Position:relative and position:absolute elements inherently depth-sort over non-positioned (position:static) elements - so we don't need to play with z-index at all. I declare the width just to trip haslayout since IE can be a bit funny with menus - strip the bullets, and I set text-align to center the menu text in their boxes.
#mainMenu li - position:relative in this case is for absolute positioning our UL. This way we can start with them positioned off-screen on the left, and then slide them into place on 'hover'. I float them since thier child elements are going to float, and the display:inline is to deal with IE being a bit of a retard about margins on floats and 'perfect width' addition.
#mainMenu a - our anchors are of course floated, and I set a fixed width on them so they will add up to the full width. I did this because I wasn't certain just what effect you were trying for with your version and this looked nice. Again you'll see top/bottom padding with a line-height to add up to our total height. This centers the text and gives us 48px total height without acutally saying it.
#mainMenu li ul - and here's our absolute positioning. The display:inline is so that we have a display state change (I change it to block) on hover. Without that IE will often 'stick' with the menu still open when you move the mouse off of it. Don't know why, but it works. You can see I move the menu left:-999em; Since we're running 100% font-size that works out to somewhere around 16K px, we'll never see it, but screen readers will still read it. The top position is of course the height of our anchors, and again I declare the same fixed width on it. Doing so makes the menu behave a bit better and look nice.
#mainMenu li:hover ul - when we hover our parent list items, we want the child UL's to slide into place. So here's the left:0 to do so, and the display:block so IE won't 'stick' open. Kind of funny since position:absolute elements are inherently display:block, and nothing you set for display can change that.
#mainMenu li:hover a - when we hover the top level line items, we want the background to change so we do that here. We do this off the LI instead of the A since we want it to stay lit up when you mouse-over the submenu.
#mainMenu li:hover li a - but we don't want the child ones to light up, so we need to strip their background. We also give them a smaller top and bottom padding, and make sure that the text won't wrap to multiple lines. [i]NOTE they will also inherit the 225px width off the #mainMenu a declaration, as well as any other values set there![i]
#mainMenu li li:hover a - but we want the nested ones to light up, so we put the background on them again. This can get rather convoluted the deeper you nest your menus, which is just part of why I don't do three level cascades.
#content - just some padding and float clearing behaviors. Nothing fancy.
#content p - Fonts and padding. Yay.
.plate - those standard "plates" I mentioned in the HTML. Two of them float, one doesn't. I tossed in all three since generally I include them for quick/easy formatting. It's worth noting if I am designing the page for RTL instead of LTR I'll reverse the floats on those; part of why I do NOT call them 'left' and 'right'. 'left' and 'right' are presentational names, and presentation has no place in the markup.
#footer - padding, bgcolor, align... again, nothing you have not already seen.
I know the sizes and paddings aren't a 100% match - I just belted this out quick though frankly, you had WAY too much white-space for my tastes given you were already on a fixed-width layout...
But that's it, how I'd approach that. Said approach working in all browsers, though I'm pretty sure what I did with the menu is not what you were thinking... If you could explain that better with a picture of your FINAL idea, I can point you at a clean way to code that which will work in IE 6/newer without problem, and quite likely IE 5.x too.