I was thinking, can’t I remove the height from the header div? This will cause a gap between navbar and header? Am I right in thinking this?
Thanks mn but th etechnique for implementing those tabs I got from the sitepoint book: the css anthology. 
Thanks for the comments! I can really learn from this stuff!
Thanks for the help! I didn’t realize that a ul tag generated default margins! I learned something! Thanks!
Yes, but for the same reason as above. There is default top and bottom margin on the H1 element. If you remove that, then you don’t need the height on the header, and no gap will appear.
#header h1{
[COLOR="Red"]margin: 0 0 0 10px;[/COLOR]
}
Do take note of deathshadow60’s comments, though, as he always goes beyond the immediate question at hand to actually teach good practice.
So you’re still using Firefox 2.0 - or are you using the text-size option INSTEAD of zoom? In which case, yeah it breaks, but anyone who gives a flying **** about zoom probably isn’t relying on firefox in the first place. Sorry, Opera user in me just flared up. There’s a reason prior to FF3 I used to say that firefox resizes content like nyetscape 4’s sweetly retarded cousin… (which I still say about a LOT of gecko’s behaviors - oh yeah, it’s a new engine following the standards unrelated to 4, sure it is…)
You’d be surprised. It’s WHY px fonts are used there - I’m not going to bend over backwards if legacy versions of firefux or the handful of people using it’s stupid/broken legacy resize technique don’t realize that px fonts shouldn’t be resized unless you’re going to resize ALL px metric containers and elements. (one of the few things I still say IE always got RIGHT)
I’m a large font/120 dpi user, so I hear what you are saying, but text-resizing has gone the way of the dodo which is why NONE of the current browser default to doing it. (well, I’ve not tested Saffy lately)… Even firefox doesn’t default to doing that and instead zooms EVERYTHING by default - meaning none of this breaks… Though if you care about enlarging content for accessibility you should probably be on IE or Opera in the first damned place.
That’s just one of the places both Gecko and Webkit fall flat on their faces - accessibility.
It’s funny you say that, as it’s something I too am obessesed with and complain about on a lot of websites, but it sounds like you are using pre-2001 techniques for content scaling instead of the MODERN approach - which is why I make anything with an image interaction that WOULD break on resize as px so it doesn’t - but ALWAYS leave my content as %/EM or even PT.
SOUNDS like you might want to look at setting your computer (if windows) to large fonts/120 dpi or if Win7 even higher, and/or changing the default font-size in your browser if said browser (gecko, webkit) ignores the system metric.
I hear what you are saying, but even if you overpad it with “10 foot” win7 users going 200% or more on the system metric you’d end up overpadding it so much it would suck on normal systems, much less 72dpi CE… the image would grow too large - and besides, people using broken/outdated zoom methods should be used to sites breaking by now - that’s why FF 3.5+ damned near hides resizing JUST the text.
On to the CSS. Follow along with:
http://www.cutcodedown.com/for_others/rockarena/screen.css
First two declarations are that “reset” people mention. You can’t trust the default paddings and margins across those elements, so null them. Likewise I rarely need/want borders on images or fieldsets, so I null those too. To me it beats the ever living tar out of declaring margin:0; padding:0; on every blasted element I’m setting up. There are larger resets like Eric Meyer’s “reset reloaded”, but that’s too saggy around the midsection and I don’t agree with 90% of what it wastes it’s time setting - there’s the minimalist “* { margin:0; padding:0;}” but that pretty much screws form elements like inputs cross-browser… I won’t go without, so I end up somewhere in the middle.
body - I added the top/bottom padding because you can’t trust margin on your first code element not to collapse. It’s a bit smaller than what you had… that’s because going 400+ px tall before you get to the actual page content is IMHO really bad design. A lot of people are too lazy to scroll down… To that end I’d suggest shrinking the logo height too.
The comment on the text-align says it all. Legacy IE (or modern IE if stuck in quirks mode) doesn’t center on margin:0 auto; like the rest of the world but will incorrectly obey text-align to do so. A lot of people these days will say don’t worry about it, but with the majority of windows CE/mobile still running IE 5.5 (IE6 on mobile only hit two years ago) I say spend the time to put in one extra line and follow a few simple rules. If you can make it work from one stylesheet across 5.5 to the latest of “rest of world” it’s VERY unlikely to ever break in some future browser.
Now, you’ll notice I state a full condensed font property. If you omit a style/weight some legacy browsers will ignore the whole declaration. (IE and some early mozilla builds). ALWAYS declare your body font as either % or EM. A lot of usability studies have been done and as a rule of thumb 85% gives you 14px/10em on 96dpi systems which is the ‘ideal’. I WOULD suggest switching to a non-serif font for usability reasons as well, but that’s your call… Finally, NEVER, EVER trust the default line-height cross-browser. Subtle differences can completely mess you up - and the way they inherit when you change font-size can screw you up even more. Besides, I like taller line-heights so instead of the 120-130% the CSS specification suggests browsers use (yes, suggests a range… thats’ nice and vague) I go right for 140%/1.4EM.
I have a page that explains the various issues and behaviors of font sizes across browsers and specifications. You might find it handy.
http://battletech.hopto.org/html_tutorials/fontCompare/template.html
Moving on. I changed the background color to a median cut of the image you were using, and renamed the image something a wee bit more meaningful. (background? Background for what?)
#pageWrapper - the outermost wrapper. I narrowed it to 960px so that you’d have border around the edges at 1024 with room for any browser borders and scrollbars. You were up above 1024 friendly which I really advise against if you are going to do a fixed width layout…
NOT that I personally would do a fixed width layout; at the very least I’d open it up semi-fluid from 768 to 1120. (that’s 800 to 1152 respectively - always take off 32px for browser chrome like scrollbars)
The text-align is just to undo the center we put on body.
h1 - since a page should only ever have one H1, we don’t need any id’s or classes to target it. Since EVERY other heading tag on a page should be a subsection of the h1, the site title seems the only logical candidate to be that tag on most (but not all) websites.
ESPECIALLY if you don’t even know what the content is yet.
The height:1% is the ‘holly hack’ - a fix for IE that trips a condition known as haslayout. In many cases an element ‘having layout’ will render properly in IE when a non-haslayout element will not. In this case our absolute positioned span inside the h1 needs it on the parent. Thankfully in EVERY browser height:1% is automatically calculated as height:auto; if the parent element (in our case #pageWrapper) has no fixed height declared on it.
The fonts are declared here in px because of the image interaction. whenever you have a image that is a fixed size you are best off using PX metric fonts despite this being ‘bad accessibility’ - thankfully at 64px on the h1 and 20px on the SMALL it is VERY unlikely anyone is ever going to kvetch about the fonts being too tiny there.
You’ll notice nowhere do I declare the actual height on the h1 or the small tag inside it. This is intentional and you’ll also notice I don’t declare width the same time I declare side padding later on. This is a simple rule for legacy IE support - don’t mix fixed widths or heights with paddings or border. The box model in legacy IE adds them up different (some people call it ‘broken’ – I call it a result of implmenting CSS2 while it was still in DRAFT)
In this case I just make sure all my padding, line-heights, and in this case take out the negative margin to equal the 180px of the logo. 57 top + 57 bottom + 64px line-height + 22px line-height - 20px == 180.
Finally just some fonts and colors for when images are off.
h1 small - The display:block forces the larger text to a new line, which I then pad and use a negative margin to ‘ride’ the smaller text over the larger one. Some simple color to match the image finishes our images off appearance.
h1 span - here’s the real magic. Because the h1 is position:relative any position:absolute we set will be based off the H1’s upper left corner instead of the document body’s. This lets us place the span over our text with the h1Logo.png image as it’s background. I remastered a new one based off the cached content on Google just for kicks.
#mainMenu - Floats are normally not ‘in flow’ for calculating a box (though they are in flow for CDATA, confusing, no?) so we ‘need’ to set up some wrapping here. I set a fixed height as the haslayout trigger since I figured you aren’t planning on dropdowns since these look like tabs. List-style strips bullets, and padding/background-color are nothing too fancy.
#mainMenu li - This is kind of a new technique I’ve been trying out. I’m floating them, padding one side, fixing the height, and setting them to overflow:hidden. The overflow here is so that any excess size we put on the anchor will be chopped off. The side padding isn’t just to space our li apart, but also to make room for our images so should you want to use transparency on those corners, there’s a way to do it.
For a moment, look at the image I used for that:
http://www.cutcodedown.com/for_others/rockarena/images/mainMenu.png
By sliding the background around AND moving the anchor inside it’s LI, I’m able to show just the parts of that image where we want them. It’s kind of an ‘uber-sliding doors’ using just one image. The top quarter being the normal button state, the next one down being the hover, the one below that being the ‘current’ button, and the final part being the ‘current’ one when hovered.
Oh, and I touched up the rounded edges, the anti-aliasing on them was a bit questionable.
So lets make that work.
#mainMenu a - position:relative is so that we can absolute position our span as needed. The float is mostly there for IE7 to behave properly as normally I’d be using display:block or have the LI display:inline;
Now the padding takes some explanation. Again I don’t declare a total height, and instead add up the padding and the declared line-height to reach the 32px I did the images for. You’ll notice I use a lot of multiples of 8. The side paddings are not identical because we don’t want it too large on the right since that’s where our image goes. If we made both sides 12px and then slapped our right corner image atop it, if we were using transparency the anchors top-left background image would show through. Hence the 12px padding on the LI. The background-image is aligned top left, and due to how this technique works we won’t have to restate that. (MOST hover techniques do!)
Oh, and the fonts are in PX because we have a image behind them. Using dynamic fonts would break - thankfully 14px in bold isn’t illegible to most large font/120 dpi users, though it is on the edge.
#mainMenu span - our top right image is 12px wide, and slid over 8px into the padding on the parent LI. This gives us 4px of overlap to the padding on the parent anchor on purpose - Firefox can be a real retard sometimes about what ‘right’ and ‘center’ means, so having some overlap prevents it from looking TOO screwed up when gecko drops the ball. We just set the image here to “top right” to show the corner we want. The really tall height is cut off by our overflow, which we’ll use to our advantage.
#mainMenu a:psuedos - the hover/keyboard states rather than mess with the background position, we use a negative margin on top to slide the entire anchor up, and then increase the top padding to show just the part of the background we want. The overflow on the LI chops off the difference. The advantage to this is we only need to target the anchor on hover, and not the nested span as well. Ends up a lot less CSS.
#mainMenu .current a - Gets slid up even more to reveal the backgrounds we want.
#mainMenu .current a:psuedos - Slide it up even more for our final hover state.
#mainMenu .current span - just some color matching. You’ll notice across the whole thing I declared colors so that images off users still get a fairly attractive page.
Which finishes off the menu.
#fauxColumns - float wrapping, that little background-image for the border between columns. Nothing fancy.
Content - float it, as a matter of habit I set it to display:inline to prevent IE from wierding out on margins, give it a width, and I pad the top and bottom just to make it pretty. Notice that’s top and bottom and NOT the sides - avoiding that mix of the two I mentioned earlier.
#sideBar - since you only have one sidebar and are fixed width, I went the easy route of just giving it a margin-left equal to the Content float. That margin will ride under the float giving us our column without the headache of dealing with a second float. You go fluid or semi-fluid you’ll need to be more complex, but it’s good for now.
h2] - just some nice padding and font size. Again I use the full font declaration because you can’t trust the default line-height, and it’s really no larger than if you said “font-size:140%; line-height:140%;”
p - I prefer padding on my P to margin just so I don’t have to worry about collapse issues. 0.5EM top/bottom between para’s makes a 1EM line-break that’s quite attractive, and it explains why I put 0.5em padding top/bottom on both Content and #sidebar to make that same 1EM total.
All in all pretty simple - hopefully you’ll be able to follow along and extract some useful information from it. Any questions fire away.
Hope this helps. (sad part is the CSS explanation took longer to write than the CSS)