… and we’re moving.
On to the CSS, follow along with the bouncing ball.
http://www.cutcodedown.com/for_others/owz2004/screen.css
First thing I do in EVERY CSS file is use a reset. Now, resets are a subject that have been beaten to death in pretty much every thread where someone uses on. I’m gonna say this quick:
You have to Goldilocks it. There are smaller resets like the “universal reset” of “* {margin:0; padding:0;}”, but that shtups form elements so stay away from it. There are larger ones like Meyer’s “reset reloaded” – but when you have 2k of CSS before you even start writing your own? Not a good thing. Frankly his is big enough to qualify as a framework since it targets elements I rarely use, or set five or six different values for across the page.
The one I advocate is IMHO “just right”. It resets just the things I need set the same across all browsers, and nothing more.
/* null margins and padding to give good cross-browser baseline */
html,body,address,blockquote,div,
form,fieldset,caption,
h1,h2,h3,h4,h5,h6,
hr,ul,li,ol,ul,
table,tr,td,th,p,img {
margin:0;
padding:0;
}
img,fieldset {
border:none;
}
It’s not even a quarter of a K.
As to the people who say resets are unneccessary or wasteful, my pages work all the way back to IE 5.x with little if any extra coding. How are those broken in everything except Firefox at small fonts/96 dpi pages coming along? 
hr - as mentioned in the HTML breakdown, I use HR for CSS off users, so for ‘screen’ we can strip these right out. If we want them inside an area we can always set them back to display:block;
body - first is a text align so our wrappers center in legacy IE. It’s one line, big deal, safe to send to all browsers. Like most of what you are going to see in the CSS for legacy IE support altogether it’s going to be less code than a conditional comment would be in the markup… Gee, send it once and have it cached in the CSS, or send it every single time the user loads a sub-page… Gee, lemme think.
Next is my default font settings. 85% of the default 16px for 96dpi systems gives you a nice 14px, while for large font/120dpi users like myself it delivers 17px - both look pretty good. You can see I use a pretty tall default line-height, I find the default can be a bit hard to follow when long lines wrap – much like double spacing helps on a 8.5x11 sheet, increasing the line-height can help on screen as well.
Finally the background color, no need to explain that.
.widthWrapper - the positon:relative is to help with positioning the menu, since we want it to render over the h1 for screen, but not in the normal document order. The text-align returns us to ‘normal’ after the IE 5.x centering, and finally width and auto margins.
#header - padding is pretty obvious, as is the margin and border. Using border on this div beats the tar out of wasting an entire extra DIV on making that blue line. Because #header is around the first .widthWrapper it will render full screen width.
#header .widthWrapper - and because it’s wrapped by #header on the first one, we can target the first one. This padding pushes the h1 and paragraph down to make room for the menu and search when we position them.
h1 - relative positioning is for the image replacement span, the float is fairly obvious as is the width. You’ll notice I do NOT specify a height because I want to use top and bottom padding. Mixing height/width with padding or border in the same direction is a recipe for failure not just on the broken box model, but ocassionally if other rendering oddities crop up in browsers like Opera (see the redraw on scroll bug)… So just don’t do it. I’ll cover the solution in a moment.
h1 small - smaller text, color, display:block makes it use the 16px line-height declared on it instead of the 18px of the parent h1. That’s a cute little quirk in most browsers, a BR will make a newline that’s got the current line-height, so if you make a shorter line-height on a display:inline element after it, you’ll still get the old line-height. Display:block removes that defined line, but thankfully doesn’t insert an extra line-break.
So how do I get the 48px desired height? Simple, 7px top/bottom padding = 14 px. 14px + 18px line-heihgt + 16px ‘small’ line-height == 48.
h1 span - This is called gilder-levin image replacement, or at least it’s a take on it. ‘real’ gilder-levin puts the span first and skips saying ‘top’ and ‘left’, but I’ve had that break in recent builds of both firefox and Opera, and putting the span last in the markup opens the door to other techniques.
It’s pretty simple, make a span, make it big, absolute position it over the text, and load the image as the background hiding that text.
#header p - I set the width in EM because I wanted to leave this text to dynamically size. Since there’s MORE than enough room for it to grow to over 500px wide, this gives us consistent wrapping behavior without having to specify BR in the markup.
For SOME wierd reason IE 6 is ignoring the text-align:left on .widthWrapper for the paragraphs, so I had to restate the text-align.
From there just set the font a little bigger and set the color. You’ll notice I declare the full condensed font property EVERY time. The reason I do this is omitting values on the condensed version tends to break in older versions of Gecko and Opera, and by the time you type out font-size and line-height (which you should ALWAYS do both) it’s almost the same number of characters, so screw it – say the whole thing so you can be 100% certain what’s being set.
#header em - since we’re coloring the EM, we strip the italic off it. We’re just implying the emphasis differently. (emphasized does NOT mean italic!). The word-wrap prevents the EM from being broken up in the middle which helps make it attractive, and I set the black color for if you add something without a color class so it will still at least stand out.
#header .standoutn I’ve got four of these, it’s just you colors.
#header ul - our main menu. We absolute position it over the heading and paragraph, give it that bottom border and strip bullets.
More complex is the overflow state and height, I use this to make the hover states. Rather than restating the background-position over and over and over, why not just relative position the buttons on hover sliding them ‘up’ while increasing the top padding? This will ‘reveal’ the lower parts of the image!
Oh, and the background-image is for the outer-bar that the search will be positioned into.
#header li - float 'em, pad’em. done.
#header li.endCap - this one gets a fixed width and that rounded corner for the search area.
#header li a - the real gruntwork goes on in the anchors. Relative position them so we can slide them around, float 'em into place, and much like I did with the h1 I use padding top and bottom with the line-height to create my total desired size.
You’ll notice I’m using PX fonts. Yes, I rage against PX fonts on CONTENT, but menus are often stuffed into crammed spaces and would break horribly if allowed to resize as %/em would, so px is the order of the day. When using PX 14 is about as low as I would EVER consider going. 12px for lf/120dpi users is just going to send them diving for the zoom, in which case you can bet they’ll not visit again. (and I put more emphasis on repeat visits than I do first-time!)
You’ll notice the right padding is 2px less – that’s for the span which makes our right edge rounded corner… get to that in a moment.
#header .singleLine a - because there’s only one line we need more padding (16px total) to make it look centered top to bottom.
#header li a span - absolute positioned inside our anchor to draw the right half of our button. This way it’s dynamic-width on all of them so you don’t have to customize the image just to change the menu!
You can see it’s declared REALLY tall, this is cut off by the overflow:hidden on the UL, but will reveal itself when we move the element on hover… speaking of hover:
#header li a:psuedostates - You’ll notice I trap :active, :focus and :hover. This is so keyboard navigators across all the different browsers aren’t left out in the cold. In theory you might want to consider adding outline:0; here, but I leave it in. All we do to hover is slide the entire anchor up until the desired vertical slice is revealed, and pad the top to push the text back down where we want it. I also set a background-color for users with images disabled but CSS on.
#header .singleLine a:psuedostates - the single line version just needs a taller top padding.
#header li a.current - in every browser except IE6 we could just declare these, but 6 can be a real dipshit about specificity overrides when it comes to psuedostates, so we have to slap !important on a few of these for them to take. Much like the hover state all we do is slide it up with a negative value on ‘top’ and pad the top to push the text back down into place. From there it’s just color. In testing IE obeys the color for some reason so it doesn’t need the !important like the others. (wierd)
#header .singleLine a.current - as before the singleLine versions need 8px more top padding.
… and that’s the menu. The ‘overflow’ cutoff with sliding around a really huge anchor is a VERY handy technique for not having to say background-position over and over and over and over and over.
#header form - the search form is also absolute positioned, in this case over the menu UL which already drew our background for it. As such we can just put the smaller ‘inner’ image for the INPUT there. By putting it as a background on the wrapper we can avoid all sorts of pain in the ass nonsense trying to put it on the input creates.
#header .searchArrow - since the submit is a nice simple image, just absolute position it.
#searchField - With the form input[text] since we had to have a ID on it for the LABEL[for], I use it instead of trying to target it off the wrapper. I avoid changing the height, padding or border-width if at all possible since cross-browser changing those values is WILDLY unpredictable. We’re talking a real nightmare. As such I just make the border the same color as the background to hide it, set a width (which will vary cross browser but not enough to matter!) and use margin to just nudge it into place. It actually renders one px lower in gecko based browsers than it does in ANY other browser due to the nyetscape heritage of being a total dink and ignoring vertical-align - I don’t consider 1px off to be worth diving for the hacks to correct. Oh yeah, gecko was a clean break from the Nutscrape 4 codebase, sure it was
Showcase - I set up float wrapping behavior just in case you use a image that’s smaller than the floated content box. Whenever I use overflow:hidden and a haslayout trigger, I like to put comments on them since not everyone will realize that’s why they are being called.
Showcase .content - I might use the .content class elsewhere since other things might have content. Most people will end up doing something silly like “.showcaseContent” or some such - I just target off the parent.
Float it, width it, height it.
Showcase h2 - as you change the content here away from the lorem-ipsum text, you’ll probably want to adjust the top padding to keep it centered. There are other methods of handling that, but they are unpredictable at best and I like to keep it simple.
Again we use PX metric fonts, again I HATE doing that, but this entire element is fixed height, so we’re not left with a lot of choices. Just be warned that in most places if someone is still using the old outdated text-resize in gecko browsers where it resizes content like nyetscape 4’s sweetly retarded cousin, the layout is going to have issues… Not a lot that can be done, sacrifices have to be made somewhere and it’s why since 3.5 dropped that’s no longer the default behavior for zooming. (though many people still set it back and then wonder why sites are broken – duh, this isn’t 1997)
Woah, we’re halfway there. Wooooaah, living on my hair…
Showcase p - fonts, padding. nothing to write home about. Notice though that on both the P and h2 I used padding on these elements instead of margins on the wrapping div.content. Since .content has a width on it, remember what I said above. Width/height + padding or border on the same element == broken layout.
Showcase .needHelp - I set the anchor to block so we can set top and bottom padding on it bringing us up to our desired 51px total height. Left margin serves the same purpose as the side padding on the h2 and P… I usually avoid margins right up until I already have padding doing something… like here. Color and background-image are nothing fancy. We can’t declare a background-color here since the .png has transparency (I converted it to palettized instead of the alpha you had – which PSP7 HATED your png BTW!?!)
Showcase .needHelp:psuedostates – I gave it a hover state.
#rotator - the relative positoning is so the images can be layered one atop the other making whatever .js it ends up with have a easier time of it. Too many of these things don’t take the time to leverage CSS to do their gruntwork. The left margin makes 100% sure it always is pushed off the float. (the IMG tag can be a bit unpredictable at times)
#rotator img - and then we absolute position the images. I force the width, but leave the height alone so aspect will be preserved.
Oh, and I resaved those as .jpg since 300+k apiece was just a little ridiculous. Just one of those images was 2.5 times larger than I usually allow as the upper limit for a PAGE on a site (as in images + markup + css + scripts!)
#firstColumn - float it, width it, pad it, give it that gradient background. I made both columns equal width which made things a lot easier to style/caclulate. 960px-16px padding for the gap between the columns == 944px. 944/2==472.
.articleBrief - float wrapping because of the floated image, margin since using padding would break it in legacy IE, and using width as the haslayout trigger since zoom is invalid CSS and height would be obeyed thanks to the overflow. I use the actual px instead of auto for the centering since IE 5 ignores auto and I don’t feel like messing with text-align:center on it’s parent.
.articleBrief img - float it. Oooh, impressive.
.articleBrief h2 - the left margin makes certain if it wraps it will not wrap under the image. the padding is to make room for the arrow image, and then it’s just a matter of setting the font. FINALLY we have a content section using %/em fonts so it’s not a total accessibility /FAIL/ like that banner area.
.articleBrief h2 a,
.allStories,
.picBox a - all of these pretty much end up styled the same, so I put them together. turn off underlines, set the color. I would NOT set that globally as normal link behavior in large content ares is something you should NOT be messing with. On headings or ‘read more’ links sure, but you get a link in the middle of a real paragraph of text, leave it the *** alone or at least TRY to preserve the behavior.
.articleBrief h2 a:psuedostates,
.allStories:psuedostates,
.picBox a:psuedostates - mess of code just to set up the targeted hover behavior of restoring the underline. It’s ugly, but whaddayagonnadoaboutit?
.articleBrief p - padding, margin to avoid the floated image and if long text wraps, not wrap under the image, color.
.allStories - this ‘readmore’ link just gets some side padding, as the natural padding and margins around it work out just fine. display:block makes sure it behaves how we want, and again we use margin to push it in since the left padding is being used to make room for the arrow image.
#secondColumn - float it, width it…
#tagCloud - pad it, margin the bottom, and I centered everything in it because it looked nicer to me that way. Instead of having two images for each columns rounded corner gradient, I just re-used the one from the first column now that they’re the same width. Why waste making an extra image when you don’t have to? Besides, it gives it a more consistent appearance.
#tagCloud h2 - padding, font-size, nothing fancy.
#tagCloud ul - ooh look, strip the bullets and do NOTHING else.
#tagCloud li - display inline so they all end up on one line with normal word-wrap behavior.
#tagCloud li a - I set inline-block on these (with the -moz workaround for legacy gecko) so we can set some horizontal padding. Many tag clouds try to stuff everything in as tight as possible, making it hard to read and useless as a nagivation aid. I like to add a bit of padding and use a consistent line-height so it’s clearer what’s what. (can you tell I hate the stupid overlapping animooted ones?)
I also set them all to ‘blue’… the .grey class can override that later.
#tagCloud li a:psuedostates - underline on hover.
#tagCloud .small,
#tagCloud .medium,
#tagCloud .large - 80%/100%/120% size gives a nice even spread, though I put bold on large. The real trick is the line-height. 150% of 80% and 100% of 120% both equal 120% of 100% – so all our line-heights end up equal! This is something people using %/em heights often don’t accomplish.
#tagCloud .grey – it’s… grey.
.picBox - float, display:inline normally prevents IE margin doubling. While technically only the second box needs it, there’s no harm in sending it to both and who knows, just in case. Again the width is easy - 472px - 16px padidng between columns == 456. 456/2 == 288. Sad part is because it’s all multiples of 2/4/8/16, I can do it in my head… Though a bit of advice – when possible keep your images and columns multiples of 4 or 8. Since computers work in binary, direct exponents of two and multiples of 2, 4, 8 and 16 can actually be processed faster by the machine… and it makes the math a lot simpler to do in your head.
Oh, I also set text-align to center again because I thought it looked nicer.
.secondPicBox - The left margin gives us the space between the columns, while the negative right margin prevents IE from having ‘float drop’ when our width is ‘exactly right’. It’s a sneaky trick but it works – in a LOT of cases it’s easier to make your columns with everything floated the same direction, so knowing that trick is important.
.picBox h2 - padding, font size. Impressive – not.
.picBox img - the display:block prevents it’s inline behavior from adding or removing oddball paddings around it, but then we need to use margin:auto to center it as it’s now ignoring the text-align in standards compliant browsers (but not in legacy IE)
.picBox a - the inline-block is there to let us set top and bottom padding without wasting a block-level container around it. I fixed the font-size on this because it looked really silly when LF/120dpi made it big enough to wrap.
Are we there yet Papa Smurf?
#footer - clear the two floated columns as we don’t have a parent element around them to apply self clearing to, pad the top and bottom to space it out a bit, and… text-align right? Yup, that way that anchor after the floated list will appear on the right without any extra wrappers! This won’t effect the UL since it’s FLOATED.
#footer a - since they all got the grey, let’s set them all to grey.
#footer ul - turn off the bullets, float it.
#footer li - you’ll notice I set LI to display:inline a LOT. Generally unless you are really lucky they’re more hassle than they’re worth on lists like these, so just inline them to basically strip their behaviors clean off 'em.
#footer ul a - float 'em, pad 'em, border-em on the left.
#footer ul .first a - the first one we strip the left padding and border, since it doesn’t need them. Since we only set this on one side, we don’t need a .last class.
… and that’s it in a nutshell.
Hope this helps and you were able to glean some useful bits from it. Any questions feel free to fire away.
much, much better! it’s a disaster waiting to happen. i had the same conversation over this forum, and i’ve argued: even if the workstations are blocked and are erased on reboot into an initial frozen state, the servers are not.