adding border in addition to rounded corner css

Good morning,
I've just learned how to make rounded corners in css, (see the code below for my navigation menu) and see it live here. www.centralmaineweb.com/mi/ - however, I also want to be able to put a real 2px border around it as well...(like is around the box above the menu that says "Manufaturers of qualit..." etc. Is there a way to accomplish this using css or do I have to revert to the code and image heavy way? Thanks much! (ps I emboldened the code that creates the rounded corners below)

======= code=========

<table width = "100%" align = "center" cellspacing = "0" cellpadding = "0">

<tr><td style = "-moz-border-radius: 15px; border-top-left-radius: 15px; border-top-right-radius: 15px; height: 30px; text-align: center; padding: 0px; background-color: #808084; font-size: 12px; font-weight: bold; color: white;">MAIN MENU</td></tr>

<table width = "100%" align = "center" cellspacing = "0" cellpadding = "0">
<tr><TD class = "buttons" valign = "middle" onmouseover="this.style.backgroundColor='#DEDEE2';"
onclick="window.location.href='index.shtml'"
onmouseout="this.style.backgroundColor='#004071'">
<a class = "menu" href = "index.shtml">Home</a></td></tr>

<tr><TD class = "buttons" valign = "middle" onmouseover="this.style.backgroundColor='#DEDEE2';"
onclick="window.location.href='about-heat-pumps.shtml'"
onmouseout="this.style.backgroundColor='#004071'">
<a class = "menu" href = "about-heat-pumps.shtml">About Us</a></td></tr>

<tr><TD class = "buttons" valign = "middle" onmouseover="this.style.backgroundColor='#DEDEE2';"
onclick="window.location.href='resources.shtml'"
onmouseout="this.style.backgroundColor='#004071'">
<a class = "menu" href = "resources.shtml">Information &amp; Resources</a></td></tr>

<tr><TD class = "buttons" valign = "middle" onmouseover="this.style.backgroundColor='#DEDEE2';"
onclick="window.location.href='photos.shtml'"
onmouseout="this.style.backgroundColor='#004071'">
<a class = "menu" href = "photos.shtml">Photos</a></td></tr>

<tr><TD class = "buttons" onmouseover="this.style.backgroundColor='#DEDEE2';"
onclick="window.location.href='contact.shtml'"
onmouseout="this.style.backgroundColor='#004071'">
<a class = "menu" href = "contact.shtml">Contact</a></td></tr>

</td></tr></table>
<table width = "100%" align = "center" cellspacing = "0" cellpadding = "0">

<tr><td style = "-moz-border-radius: 15px; border-bottom-left-radius: 15px; border-bottom-right-radius: 15px; height: 20px; text-align: center; padding: 0px; background-color: #808084; font-size: 12px; font-weight: bold; color: white;">&nbsp;</td></tr>
</table>

 

Your code seems to be over complicating it.

style="border-radius: 15px; border: 2px solid black;"

Code (markup):

You can change the border color and side if you want to.

 

Interesting! Yes, I simply copied, pasted and tweaked this from a css site, but they were pretty adamant about the mozilla part, due to Firefox. Also, I need only the top left and right of the top td cell and bottom left and right of the bottom cell. Let me tweak what you've pasted here though and I'll respond in a bit. Thank you!

 

wow! strangely, this time it worked. (see pasted). Now I want to encapsulate the entire menu in a white border so I think I need to do a "wrap" of one td with all four corners rounded, border white, with the rest of the menu as separate table within. I think I got it! You're my hero this morning!

<tr><td style = "-moz-border-radius: 15px; border-top-left-radius: 15px; border-top-right-radius: 15px; border: 3px solid white; height: 30px; text-align: center; padding: 0px; background-color: #808084; font-size: 12px; font-weight: bold; color: white;">MAIN MENU</td></tr>

 

Check out what I've done now. http://centralmaineweb.com/mi/ - I simply wrapped the whole table in one table cell with the rounded corners, then applied some top and bottom padding to customize the size.

 

That looks great! I'm glad I could help

 

Many thanks to you!

 

WHY do you have a menu in a table? A MENU is not tabular data.

WHY are you using onclick when there's a perfectly good anchor inside it?

WHY are you declaring presentation in the markup?

WHY are you applying border-radius to elements that by the specification (even if webkit obeys it) aren't supposed to obey border-radius and do not do so in many browsers?

WHY are you using JavaScript to do CSS' job?

WHY are you declaring your fonts in an area that should be elastic in pixels? You do know that uselessly undersized fixed metric 12px is accessibility trash, right?

Laundry list of how NOT to use HTML, CSS or JavaScript.

There is NO excuse for the markup on that to be much more than:

<div id="mainMenu">
	<h2>MAIN MENU</h2>
	<ul>
		<li><a href="index.shtml">Home</a></li>
		<li><a href="about-heat-pumps.shtml">About Us</a></li>
		<li><a href="resources.shtml">Information &amp; Resources</a></li>
		<li><a href="photos.shtml">Photos</a></li>
		<li><a href="contact.shtml">Contact</a></li>
	</ul>
<!-- #mainMenu --></div>

Code (markup):

With the CSS being something like this:

#mainMenu {
	padding-bottom:1em;
	color:#FFF;
	background:#808084;
	-webkit-border-radius:1em;
	border-radius:1em;
	border:2px solid #FFF;
}

#mainMenu h2 {
	text-align:center;
	font:bold 100%/200% arial,helvetica,sans-serif;
}

#mainMenu ul {
	list-style:none;
}

#mainMenu a {
	display:block;
	padding:0.25em 0.5em;
	margin-bottom:0.25em;
	text-decoration:none;
	color:#FFF;
	background:#004071;
}

#mainMenu a:active,
#mainMenu a:focus,
#mainMenu a:hover {
	background:#DEDEE2;
}

Code (markup):

That's it. No scripting, no goofy non-semantic table crap in your markup, clean simple semantic HTML and CSS doing what CSS is meant to do.

 

Despite the critical nature of your post, I have to thank you. I own 3 businesses, my attention gets divided, and find myself a little behind the times coding-wise, but want to learn and catch up. I do have to admit i hate divs. I love tables. I just "see" tables in my mind much clearer. Much more logical to me, that's all. And the only reason the markup was in the html was that I was testing. I generally strip it out once I get it figured out, put in in style.css and then put a class = "" in the markup. I am actually unfamiliar with the term webkit. I've actually never even heard it before but I'll do some research here, using your post as a jumping point. I do want to do things right but frankly I am sometimes skeptical of over use of CSS. It seems like sometimes twice as much css needs to be used as html. I know there's a certain logic but I am cynical in that I am always waiting for things to hit the next level of simplification. Sometimes I think this stuff is here just to make people feel smart so they can pick on poor old blokes like me in the forums!

 

I gotta tell ya, I have stripped out most of the redundant markup but otherwise I'm leaving it alone. I just tested it in FF, IE, and Chrome on my MotoX and it's perfect. In addition the flyout menu (anylink.js) is the first flyout menu I've encountered that works nicely on smartphone. the submenu items come right out and hang out for a few seconds. If you think of it, give it a look see... www.centralmaineweb.com/mi/ - i've added links, took others away. I do plan on moving to lists for menus asap though if for no other reason so I can make a more responsive template for future.

 

check out www.centralmaineweb.com/mi/contact.shtml - i used your menu code, deathshadow, and it looks neat except there's a big space or margin to the left of the buttons...when I add a width property, that padding stays but the buttons do get wider. Can you tell what that is?

 

Initially, I was going to write this, (among some other things) : It's 2014, not 1998...
Then I figured that would be plainly hypocritical, as I've been there myself, it's difficult to keep track of all the changes in the industry. It does force us to adapt, even though we don't necessarily like the changes. It's pretty much the same thing today: those html5-tards are so annoying, aren't they? With their twisted vision of semantics and simplicity...
In spite of all that, I have to say that tables for layout, presentational markup and html3.2 methods in general are definitely not something that you'd consider as acceptable today.

Now about that padding: you just didn't reset margins and padding, and that the source of your problem. A simple #mainMenu ul {padding:0} will do the trick.
By the way, the style attribute is not mandatory! It's even bad practice (with a few exceptions), makes your markup presentational rather than descriptive, saying what things look like rather what their role is in the document.

 

Which means you're in the wrong mindset to be writing HTML in the first place; HTML is for saying what things ARE, NOT what they look like... DIV and SPAN being the only exceptions as they "have no meaning" and are "semantically neutral".

Using tables for layout isn't logical at all, becuase the contents are not tabular data. It was a hack that should have died off a decade and a half ago.

Webkit is a browser engine, forked by Apple from the KHTML engine that was used in the open source Konqueror browser. (which was originally *nix only). Webkit was recently forked by Google into "Blink" -- the engine behind Chrome and the "new" pathetically crippled Opera.

Basically:
Trident == IE
Gecko == Firefox, IceWeasel, etc.
Webkit == Safari, Old Chrome
Presto == "Real" Opera
Blink == Chrome, Chromium, ChrOpera.

That is rarely if ever true, though sometimes I think people react that way because properly formatted it's sometimes more lines of code, without being actual code.

See the tables in your original post -- you've got 2k of code there. The HTML and CSS combined from my post is barely 900 bytes, so less than HALF the code!

... and if that content is appearing across multiple pages, or you have multiple sections sharing that same appearance (which it seems you are) and that CSS is in an external stylesheet, that style can be cached across pages speeding up page-loads of sub-pages.

Leveraging CSS "properly" practicing separation of presentation from content -- aka HTML says what things are and CSS to say what they look like can mean better caching, faster page-loads, and better graceful degradation since to be frank, there is more to building a website than what it happens to look like on the screen you happen to be sitting in front of.

That's really the 'flaw' of presentational markup and dicking around making what a page looks like before you have content and semantic markup of that content -- since that presentation means jack **** to search engines, screen readers, braille readers... and one fixed presentation is probably going to leave users somewhere "wanting" given the wide range of screen sizes we're supposed to be supporting. (and really should have been supporting from the day TBL made HTML in the first place!)

Well, I'm gray matter too on this -- been programming for over three and a half decades; I just wonder "how long does it take to drag people kicking and screaming out of old practices" since to be frank, the methods I'm advocating have been around for fifteen damned years! How long does it take? SERIOUSLY?

You can see this with PHP and the mysql_ functions, where we're probably still going to have ignorant halfwits sleazing them out a decade from now, despite right now we're at eight years of being told to stop using them (pretty much from the day PDO and mysqli were introduced) and two years of giant red warning boxes in the manual telling us same.

HOW LONG?

Of course, when we have well documented HTML 4 browser implementation bugs that in two years will be old enough to legally buy cigarettes...

HOW LONG?

People talk about the computer industry moving rapidly, to be honest the past... seven or eight years to me it feels like it's slowed to a snails pace.

You've got a lot of code in there that just doesn't make any sense -- you're adding widths where widths don't belong, you're not letting flow do flow's job, and in general the whole page just needs a total 'toss it and start over'.

I tell you what -- I'll do a rewrite to show you how I'd approach that, and then do one of my infamous line-by-line section-by-section breakdowns to explain the how/what/why of it. I do these from time to time to try and help educate people on why all these approaches make far more sense and are far EASIER to work with than continuing to have one's cranium stuck up 1997's rectum using decade and a half out of date coding practices that to be frank, (When am I ever anything but) weren't even proper use of HTML back then!

First off, sorry for what I'm about to say, I am partly just venting over dealing with a slew of jacktards across various forums that react far, FAR worse to my posts than you did.

You know, I'm getting really sick of that ****, "oh noes, someone is being critical" crap -- especially given how tame a response that one was it still apparantly triggered the "Someone was critical ****AAAAAH NOES, NOT THATZ****" response.

Seriously, what the hell people?!? Grow a pair! I really wonder how anyone even manages to go through a business day with attitudes like that; but then I look at the current state of education, business and the economy and go "OH, now I get it". Everything carefully crafted so as to rouse the least emotion and avoid the mere possibility of offending anyone... the end result being nothing ever gets done properly, improved over time, or even corrected.

To hell with that and to hell with that type of "status quo FTMFW" attitude.

Sorry, pet peeve. I'd hate to see how most of the wussies out there would handle me if I went into full-on DI mode and bothered instructing "properly" instead of the watered down approach I use on forums. MAYBE it's my being a died in wool New England Yankee, maybe it's my period of military service including OCS and instructor training, maybe it's that I learned business in the late '80's and early '90's...

But really, I wonder just what the hell is wrong with people these days. It's like people cry for help, but they don't want to BE helped; hence why IMHO the whole "it's not what you said, but how you said it" crowd can pretty much go plow themselves.

Help should be critical, because if you need help, YOU'RE PROBABLY DOING IT WRONG! That means you need to be told WHAT you are doing wrong.

Heaven forbid...

 

Ok, I did that rewrite and... something REALLY bad happened. I started to have fun with it.

Now this is what I came up with:
http://www.cutcodedown.com/for_others/KennethLaVoie/template.html

... and as with all my examples the directory:
http://www.cutcodedown.com/for_others/KennethLaVoie/

is wide open for access to the gooey bits and pieces. I included several extra files I'll use to explain the thought process and the how/what/why of it, and over the next few posts I'll be breaking it down piece by piece for you. Basically, you follow this, and in one day I can bring you up to speed.

It should be noted this rewrite is an elastic, semi-fluid AND responsive design... to do it I had to redo the header image (you might want to have a real artist do that 'for real' -- that was a quicky) which to be frank, I'm not sure I'd deploy on a real website due to it's fixed nature not being conducive to accessible design.

First, let's talk one of your misconceptions. I said before "Seems like you'd write more CSS" -- if you are writing more CSS than you would have as markup, your writing your CSS wrong. Your existing CSS was proof of that even in it's first few lines!

a:active { color: #000000; text-decoration: underline; }
a:link    { color: #000000; text-decoration: underline; }
a:visited { color: #000000; text-decoration: underline; }
a:hover     { color: #000000; text-decoration: underline; }

a.menu { color: #ffffff; text-decoration: none; font-weight: bold;}
a.menu:active { color: #ffffff; text-decoration: none;  font-weight: bold;}
a.menu:link    { color: #ffffff; text-decoration: none;  font-weight: bold;}
a.menu:visited { color: #ffffff; text-decoration: none;  font-weight: bold;}
a.menu:hover     { color: #004071; text-decoration: none;  font-weight: bold;}

a.footer:active { color: #004071; text-decoration: none; }
a.footer:link { color: #004071; text-decoration: none; }
a.footer:visited { color: #004071; text-decoration: none; }
a.footer:hover { color: #ffffff; text-decoration: underline; }

Code (markup):

The parent non-pseudo version of a tag will set ALL the psuedo's... the only reason to state a psuedo is when it's value is DIFFERENT. Likewise, as George Carlan once said 'not every ejaculation deserves a name' -- in this case not every tag needs a class. If you had targeted off the parent in the markup, you could get rid of all those class="menu" in the markup, and use a class on the UL instead to nab ALL it's children.

If I had written the same CSS, I'd have ended up with:

a { color: #000000; text-decoration: underline; }

#mainMenu a { color: #ffffff; text-decoration: none; font-weight: bold; }
#mainMenu a:active,
#mainMenu a:focus,
#mainMenu a:hover { color: #004071; }

#footer a { color: #004071; text-decoration: none; }
#footer a:active,
#footer a:focus,
#footer a:hover { color: #ffffff; text-decoration: underline; }

Code (markup):

:active, :focus and :hover all getting the same values since :focus is supposed to be for keyboard navigation, and :active is used by some legacy browsers that don't report :focus (legacy IE).

NOT that I usually set a global default anchor state, I prefer to set them as needed by section.

That's an example of why you were probably thinking CSS is 'big' -- you aren't leveraging inheritance, selectors or semantics... and that's why my HTML and CSS, not counting the media queries for responsive layout -- is the roughly the same size COMBINED as your markup was all by itself.

Alright, lemme start breaking things down for you. When I build markup the FIRST thing I do is go "what's going on the page?" -- I then take a flat text editor and write that content or a reasonable facsimile of future content -- my headings, my structure, etc -- and write it out as if HTML didn't even exist. This provides a logical document order on which I can build. I then go through and semantically add HTML tags to that content enhancing the document structure. Your base HTML should say what things ARE, NOT what they are going to look like.

I saved a copy of the code at this point. It was written as if visual style didn't exist, and completely ignores what the tags default appearance in screen media is. This is because that's what HTML is supposed to have been for all along, no matter how badly Microsoft and Nyetscape mistook HTML for the bog or how many developers over the past twenty years have ignored the rules of the language they are supposedly using.

http://www.cutcodedown.com/for_others/KennethLaVoie/markupRaw.html

You'll notice at this point there are no DIV or SPAN in there. DIV and SPAN are semantically neutral containers, and the ONLY reason to include them is to group together tags or content for the application of style that has NOTHING to do with what the content means -- WITHOUT saying exactly what that style is.

If we were to use the web developer toolbar to pull up a document structure of what you had written, it ends up looking like this:
http://www.cutcodedown.com/for_others/KennethLaVoie/images/originalOutline.jpg

It complains about the missing H1 because a H1 is the heading under which all sections of the page are subsections; which is why the usual H1 candidate for the page and in fact every page on your site -- as you can see in my rewrite -- is the site title. It's like a newspaper or book, what's typically in the top-left corner of every page? The name of the book or paper. Likewise H2 mean the start of subsections of the H1, so how can you even have H2 in your markup without a H1? Doesn't make any sense. H3 are subsections of the H2, and so forth. Likewise a HR does not mean "draw a line", it means "a change in topic or section where a heading is unwanted/unwarranted" That's why skipping numbers is gibberish, and how headings and HR can be used to divide the page into sections. It's even used to aid in page navigation by some user-agents. (and why HTML 5's SECTION and NAV are idiotic BS code bloat)

If we pull up an outline of my rewrite:
http://www.cutcodedown.com/for_others/KennethLaVoie/images/newOutline.jpg

The reason you don't use "STRONG" or "B" for headings becomes clear. I look at your original markup, and where you were using STRONG you were probably thinking "I want this bold" -- while I'm looking at it thinking "Why are you adding 'more emphasis' to this text? Isn't this a heading?"

Only once I have proper semantic markup of my content saying what things ARE, do I start applying CSS and adding the extra DIV and span as needed. I put a copy without the CSS in there to show WHY you write markup this way:
file://localhost/C:/xampp/htdocs/for_others/KennethLaVoie/templateNoCSS.html

This is pretty much what search engines, screen readers, and other non-visual user-agents would use from a page. Because we have headings and hr providing document structure it is clear to such UA's what's-what, so they are better able to identify the content. This means better accessibility, better search results, and just plain all around "better". It also means we aren't sending styling to things like "print" where we likely don't want the same style.

Let's go through the final markup "from the top".

I use an XHTML 1.0 STRICT doctype. My reason for choosing XHTML 1.0 is I prefer the consistent structural rules, and a few minor changes to how things validate. That's really the only reason to use it -- the whole XML thing is more fantasy than fact when it comes to 1.0. As to using STRICT?

STRICT is the REAL HTML 4.01 / XHTML 1.0 -- Transitional quite literally means "in transition from 1997 to 1998 coding practices" and on the whole no site written after the 1998 recommendation release of HTML 4 should be written with transitional. Tranny ONLY existed to allow old sites to add the new stuff without throwing away the crap that shouldn't even be allowed on a page in the first place... like all the deprecated tags and attributes. CENTER, FONT, ALIGN, BGCOLOR, APPLET, TARGET in non-framesets... It's all garbage that NEVER had ANY business in the HTML specification or browser support in the first place! Laughably a lot of the tags and attributes deprecated in STRICT didn't exist in HTML 3.2... not quite sure how you deprecate something that never existed.

I do not use a HTML 5 doctype because the loosening of the structural rules makes validation as pointless as using tranny -- but that stands to reason as HTML 5 seems carefully crafted for all the people who never pulled their heads out of 1997's backside. It sure as shine-ola isn't for anyone who embraced STRICT, separation of presentation from content, progressive enhancement, or any of the dozens of other improvements of the past fifteen years.

Since we're in XHTML all tags and attributes (and even some values) are lower-case. Really any HTML written after 1997 should be done in lower-case for consistency.

You'll notice I have a META[viewport] in there. This tells mobile devices not to lie (as much) about their actual resolution and no to start out with trying to auto-adjust the zoom to the page. Basically we're telling mobile that as a designer "we know what we're doing, leave **** alone!"

I put placeholder text in the description -- I'm assuming the mismatch of text was because it's a prototype template.

I also changed out the keywords META's content with some instruction on what SHOULD be there. Honestly on a contact page I'd consider leaving it out; what you had there was an overstuffed mess -- remember it's keyWORDS; not keyphrases, not keysentences, but keyWORDS -- seven or eight words (or proper names are allowed through) that EXIST INSIDE THE BODY AS PLAINTEXT totalling preferably less than 128 characters. You use anything that doesn't fit those rules, you can bet your sweet bippy it will be ignored; hell it might even get you slapped down in the rankings!

Notice on my LINK for the stylesheet I include a media target. "ALL" is always rubbish, as is omitting the MEDIA attribute. I say "screen, projection, tv" as screen is most devices you'd think of, many kiosks and browsers in 'full screen' operation use projection, and there are still some display devices reporting themselves as "TV" in operation. Doing this also means our screen layout won't be sent where it makes no sense like PRINT, AURAL, etc.

I always put <html><head>, </head><body> and </body><html> on the same lines as a reminder that NOTHING should EVER be allowed to go between those elements. It's a good way to reduce the chances of the copypasta crowd from completely screwing things up.

On to the "real" code:

DIV#top.widthwrapper -- I give my outermost wrapper the ID of #top so if I want to link to it on page "back to top" or some such, I have the ID in place. Some pages use multiple widthwrappers, some just the one, I use the same class across all designs for consistency.

H1 -- The main heading that EVERYTHING on the page is a subsection of. The SPAN inside it is a image sandbag for Gilder-levin image replacement. This allows me to have text for non-visual UA's, a proper heading, and easier adjusting of the appearance when I make the layout responsive. We'll explain this more when we get to the CSS, but for now let's just say blindly pasting a IMG tag in there is just gibberish since that's a PRESENATIONAL image -- and presentation, what things look like -- has NO business in your HTML.

#tagAndPhone -- the 'manufacturers' text struck me as a tagline, I just gave it a DIV. You had this text in the image, and that's accessibility trash and a missed usability opportunity. If it's text, GET IT IN THE MARKUP AS TEXT!

#extras -- this wrapper is for the leading column. I do not call it a column as not all layouts will use it as such. NORMALLY I'd place this AFTER the content as the content area is what's important on the page, but with the main menu in there it really goes first.

.firstHalf and .secondHalf -- a wrapper I added while making it responsive, allowing me to break #extras into two separate columns if need be.

div.subSection -- these provide the white border, rounded corners and background colors, as well as the h2 styling for both of the sidebar sections.

Inside both #mainMenu and #contactInfo there's a H2, the heading for each side-item. They are H2 as the only parent at this point is a h1, and they are quite obviously siblings to each-other.

Inside those H2 you'll see two empty self-referencing anchors. Those are used for a show/hide effect on the menu on narrow mobile devices in the responsive layout. We'll explain that more in the CSS breakdown.

The menu just gets a list, the contactInfo just gets a bunch of div for padding between sections and H3 as they are quite obviously the start of subsections of the H2 before them.


#content -- I got rid of the heading you had as it just seemed like a redundant waste of space... the illegible white text on light-gray wasn't helping matters either. For this section the secondary text you had makes a better structural heading IMHO.

Again we have H3 inside them as to mark beginnings of subsections of that H2. I gave some of them the class "inline" since we don't want display:block behavior on them.

The form got an ID to make targeting it's children easy. Like all good forms any elements the user will use to input values to go inside a fieldset; I then like to make a DIV called ".submitsAndHiddens" after the fieldset for non-user interaction fields. Keeps them separate and makes targeting elements for styling easier.

I use JUST the semantic elements for hooks to apply style inside the form. You don't need a table OR any extra DIV to do ANY of the "label next to a input on a line" stuff people throw endless extra code at for no reason. I do pull a 'cute' trick to make the INPUT dynamic width in the CSS, but again, we'll get to that in the CSS breakdown.

I added the contact_ prefix to the ID's just to reduce the odds of accidentally having multiple elements with the same ID.

After closing #content I have a horizontal rule. I do this as the footer is NOT a part of "By filling out the form below (recommended)" and doesn't have a header. HR means change in topic/section making it pretty clear of that. Again, HR does NOT mean "draw a line across the screen" -- in professional writing that's not what a rule is, and rules can have many different appearances like an elipsis, a series of asterisks, three asterisks with spaces between them....

#footer -- I put a DIV inside it on the text to allow different stylings to be applied at different widths, again without saying what that styling will be. I put the menu in a list since, well... that's what a menu is.

That's really the markup in a nutshell. One other thing is that I like to have closing comments on DIV so I know which div is being closed just in case I screw up my tab indents. (which is rare for me, but it happens to the best of us) -- you'll notice the comments are inside the closure, this is on purpose.

There is a rare, but painful bug in legacy IE and even some builds of FF where comments between sibling level elements can trip rendering bugs. Usually it happens around floats, position:relative or position:absolute, but it CAN happen anywhere at anytime without reason. If you put your closing comments inside the closure like I do, it can never end up between sibling elements meaning you never have to worry about the dreaded "double render" or "disappearing content" bugs -- handy since I've seen people waste tens of K of hacks on getting around said problems.

IT's also why I use verbose/descriptive ID's... so I don't need opening comments. Good for a laugh is when you see re-re commenting like this:

<!-- start content -->
<div id="content">

NO ***? <div id="content"> is the start of the content?!? REALLY? Never would have guessed... Same reason I don't say "end" on my closures, </div> is the end of something? Shocking really.

You'll also notice I'm a stickler for code formatting. Good way to not make mistakes, good way to make the code clear and legible... and to be frank 'whitespace stripping' to me is just a way to sweep developer ineptitude under the rug. If stripping out tabs and carraige returns saves enough bandwith to make a difference, you've probably done something wrong somewhere else in the code.

Alright, I've got to jet out the door now, but when I get back later I'll write up a similar breakdown of the CSS to explain the how/what/why of it.

 

Alright, here's the CSS breakdown.

Follow along with:
http://www.cutcodedown.com/for_others/KennethLaVoie/screen.css

When building CSS I always start out with a reset. Why a "reset"? Because some values do not have consistent defaults cross-browser. This goes with the fact that what things look like when there is no CSS is ENTIRELY up to the discretion of the user-agent; there is not nor should there be a default appearance you can assume, since that's NOT what HTML is FOR!

There are smaller resets, like the so called "universal reset" of "* { margin:0; padding:0; }" -- but throwing padding at form elements can cause some headaches cross-browser, so I advise against that one. There are larger resets like Eric Meyer's "Reset Reloaded" -- but that does a lot more than just reset things, it wastes times setting values you're probably just going to change anyways and is so big, it borders on being a framework. Really resets like that are what gives using a reset a bad name.

The one I use is a nice safe middle-ground. At a quarter of a K it's far smaller than most, without the headaches anything smaller can cause.

HR -- the comment says it all. I use HR for their semantic meaning, NOT to draw lines on the screen, so we hide these. Given that HR do not recieve styling cross-browser in a consistent manner anyways, we want a line across the screen that's BORDER's job!

@media (max-width:600px) - if you haven't seen these before, it's a "media query". Anything inside it is only applied to display widths narrower than 600px. The text-size-adjust properties inside it further tells mobile browsers that we know what we're doing, stop second guessing us! I put it in a media query so that it isn't sent to desktop versions of Safari, where those values will break zooming; which is laughably pathetic since it doesn't break zooming on mobile Safari. (Apple ineptitude at it's finest!)

html, body -- I set these to height:100% because I want our 'widthwrapper' with it's different background color to stretch the screen height. Neither height nor min-height actually work with percentage values unless their parent element has a non-auto value on it. Some browsers the top-most element is body, in others it's HTML... set both, we know we can use min-height inside it.

body -- I always like to set the most commonly used font-size and face on body. You do that, you should have MAYBE three or four other font declarations in the entire CSS file. (headers... and... well... headers). I use percentage font-sizes so they are based on the browser or OS default (whichever the browser is obeying).

In yours you were using px metric fonts, which are an inaccessible train wreck of how not to build a website because they do not auto-enlarge to the user preference. It's also why ALL of my width declarations are going to be in EM's, so that our widths are based on the font-size. Generally speaking using pixels for fonts and widths is rubbish, and should only be done when you have to under something like a image-replacement. (of which we have one on the H1!)

It's called "elastic design" and "dynamic fonts" -- which is why the page renders like this for most people:
http://www.cutcodedown.com/for_others/KennethLaVoie/images/preview_full96dpi.jpg

Users like myself who use the "8514/large fonts/120dpi/125%/win7 medium fonts / whateverTheBlueBlazesThey'reCallingItThisYear" -- which has been around since windows 3.0 -- will have the fonts and layout elements on the page enlarge thus:
http://www.cutcodedown.com/for_others/KennethLaVoie/images/preview_full120dpi.jpg

Notice the images do NOT enlarge, though more width is shown. This is NOT zooming, it's the default font size being difference. For a lot of users it's an accessibility NEED, which is why if you declare your fonts in pixels and your widths in pixels, YOU'RE PISSING THEM OFF!

There's a reason the Web Content Accessibility Guidelines says to use %/em.

I threw the text-align:center on body as a laugh to make the page center in IE 5.x -- amazingly this design is surprisingly functional in legacy IE without my really even trying; but that's just the good habits I've formed the past decade doing their job... and why I laugh when people call coding for IE "hard". People just make it hard.

.widthWrapper -- I set a min-width basically for IE 7 and 8 since they don't know media queries. The base layout I design for a page is always designed with non-media query desktop FIRST -- since that's the most likely lowest-common-denominator. A lot of people say "Design mobile first" -- but honestly I think that just results in screwing everybody over by short-changing them.

The max-width is there to prevent long lines of text from getting unweildly -- you combine min and max-width and you have what's called "semi-fluid" layout. Again, I use EM's -- based on the font-size -- so the layout ends up both elastic and semi-fluid.

There were some oddball placement bugs inside the page in IE 8 and earlier, adding zoom:1 to trip haslayout fixes a lot of such errors. You'll see me use that a few more places.

Margin auto centers things, I set the text-align back to left to return the behavior to normal after the text-align on body for IE 5 support. From there it's just colors and borders. I took a few stylistic liberties with it, like adding a illuminating box-shadow to make the background a bit less bland.

* html .widthWrapper -- if you've not seen it before, "* html" is a selector hack to say "this is for IE6/earlier". As IE6 doesn't know how to do min or max-width, well.. the comment says it. Shove a fixed width at them, and they should be thankful we even bother thinking about them at all.

h1 -- the relative positioning lets us absolute position it's child span in relation to the H1 instead of BODY. Absolute positioning is often broken in IE7/earlier, but again a zoom:1; trips haslayout to fix that buggy behavior. I avoid declaring a height as height+padding == headaches, and instead use the line-height + padding to equal the desired 300px height the image is going to be. From there I gave it some style for when the image is hidden when the layout is too narrow for it, or when images are blocked/disabled.

h1 span -- we absolute position the span over the text, and give it the 'logo' area image as it's background. Images on you see the image. Images off you see the text... best of both worlds maintaining document structure and semantic markup. I position it RIGHT and made the image wider so it doesn't show should someone be running 125% font size or more. Again, you'd probably want a real artists to clean up that image.

#tagAndPhone,
#extras.subSection -- since these both get the same colors, border and rounded corners, I nested thier selectors together. Look, one spot where you can change the colors and borders of all those types of elements... and people wonder why I call LESS and SASS "pointless crap".

#tagAndPhone -- It also gets some unique values. The position:relative as the comment says makes sure that it depth-sorts over the H1. The H1 also has relative positioning, and positioned elements by default depth-sort over position:static (unpositioned) ones. The top negative margin is what actually rides the element up over the h1 and it's span...

Negative margins are handy, but take some getting used to the idea of. The way I like to describe it is there are two separate boxes a browser keeps track of -- the render box and the flow box. The render box is what it looks like, the flow box is how big it is treated when other elements interact with it on the page. Taking 7em off the top of this element makes it 0 height, since 1.5em line height * 3 lines of text + 1 em top and bottom padding and 0.25 em of top and bottom border = 7em. So far as everything else on the page is concerned, this div is 0em tall, but it's still DRAWN as 7em tall.

#tagAndPhone span -- I set the span to display:block to force the content to three lines. This is a sneaky trick, as when we change the layout for responsive layout we can set it back to inline or set other values on it as need be to fit the available screen space.

#extras -- we float the column, set it's width, and margin it to push the #content away from it. I try to use consistent paddings across a page, and 1EM most always looks best and is easy to remember. The display:inline addresses the fact that between floats for some screwy reason IE will try to double the margin. Display:inline fixes that without effecting anything else in any browser, as that state is ignored because floats ALWAYS have block-style behaviors no matter what you set for display.

#extras .subSection -- Pad 'em, margin 'em... the rest of their style has already been set above.

#extras .subSection h2 -- the overflow:hidden is to wrap our floated hide/show anchors for the narrowest layout. We'll cover that more in the media queries below. The rest of it is just style.

#mainMenu ul -- turn off bullets. YAWN

#mainMenu li -- I set position:relative since you seemed to have a flyout menu built with JS. Done PROPERLY that shouldn't need any scripting whatsoever, this just kind-of sets up for it. IE7 will exhibit all sorts of bizarre behaviors when we hover the anchors, randomly changing heights and so forth. Zoom:1 fixes is, but this does NOT seem to be a haslayout issue as no other haslayout trigger works. In these little corner-cases we call it "zoomfix".

#mainMenu li a -- set to display:block so we can set top/bottom padding and so the entire area is hover/clickable. From there it's just appearance stuff.

#mainMenu li a:pseudo -- the three pseudo states just change the color. I set :active, :focus and :hover so that it targets more than just mouse users. I covered that in the earlier post.

#contactInfo div -- I ended up giving these the same margin between them as the anchors in the menu for consistency of appearance. Other than that, nothing really fancy going on here. I added a clear:both as for some reason Chrome was riding it up over the H2's text on the narrowest media query.

#contactInfo h3 -- font and alignment, yawn... though you'll notice I use the full condensed font parameter. I do this as when you change the font size, RESET THE BLOODY LINE-HEIGHT! You cannot trust the inheritance of line-height, especially if using dynamic fonts. Since by the time you say "font-size:100%; line-height:150%" your damned near at the same number of characters, I say "screw it" and just declare the whole thing so I can clearly see in the code EXACTLY what's being set.

Certain jack-tards out there will claim that omitting a metric "line-height:2;" will inherit properly, it does so in chrome at default font size, FF at default font-size, and NOWHERE ELSE. The laugh is no matter how many times you show the ignorant halfwits promoting said method that it's broken, they go "wah, wah, no it isn't" and stick their heads in the sand.

#contactInfo .mail -- alignment, big deal.

#contactInfo .mail a -- decoration... ditto ditto

#contactInfo .mail a:pseudo -- hover and keyboard states.

#content -- I set up some float wrapping behavior so that it doesn't try to 'sneak under' the float next to it. From there it's just simple background and rounded corners.

#content h2 - padding, fonts, yawn.

#content h3 - padding, fonts, yawn.

#content h3.inline -- set it to display:inline and strip off that padding for those two lines on the page where we want it... inline.

#content p -- padding, yawn...

#contact fieldset -- this is where we start setting up for a cute trick. Making input auto-scale to fit their container next to their label is near impossible, even with tables... but I know a way around that. WE set up a wide side-padding...

#contact label -- we then fix the width of the labels the same as that padding, and again use negative margins to slide the label over. Now the full width is available for the input/select/textareas.

#contact fieldset input,
#contact fieldset textarea,
#contact fieldset select,
#contact label -- margin bottom on all these is the same to space things apart evenly. Might as well put that together as one declaration so we can adjust that spacing easily... and people wonder why I say LESS and SASS is pointless crap... wait, did I already say that?

#contact fieldset input,
#contact fieldset textarea -- thanks to inline-level whitespace and the padding/borders on these elements we can't quite say 100%, but 98% is close enough for gov't work. The negative margin right reduces the flow width enough that we can be sure we won't have a nasty problem called "inline-drop" get in our way.

#contact_zip -- naturally no reason to make the zip full available space width, so we target it directly. I use max-width so that it can still shrink if need be.

#contact_state -- ditto ditto since people should only be entering two letters.

#contact .submitsAndHiddens -- padding and alignment for the submit and reset buttons.

#contact .submitsAndHiddens input -- I took the time to style the submit and reset button all pretty using colors similar to your menu.

#contact .submitsAndHiddens input:pseudo -- and gave them pretty hovers too.

#footer I clear:both just to be sure we get past #extra's float. Alignment, padding, color... YAWN.

#footer div I set this to inline so it rides up next to it's sibling on our 'normal' layout.

#footer div:before -- inserts a bullet we may or may not want based on the layout in there to separate things.

#footer a and #footer a:pseudo -- color, style, hover, YAWN.

#footer ul -- turn off bullets, I made the line-height tall to tweak the appearance slightly, and padded the top for same.

#footer li -- setting these inline puts them all on one line.

#footer li a -- inline-block makes them easier to click on, and some padding to make 'em purty.

That's the base layout... Now we have the media queries to make it responsive.

MEDIA QUERIES

@media (max-width:72em) -- We lower the min-width since we know media query browsers can go narrower. We also strip off the side borders to make even more screen space available.

@media (min-width:60em) -- this is working the other direction -- on really wide screens we can make the LABEL's wider, we just adjust the padding on the parent fieldset, the label's width and it's left-margin.

@media (max-width:52em) -- we get down this narrow and that logo image just isn't viable, so we re-adjust the padding on the H1 to something usable, hide the span letting our text show through. We then pull the excess margin off #tagAndPhone so it no longer rides up over the H1, and we put the span inline instead of block so it can ride up as we've got plenty of room. A nowrap property keeps that one line of stuff together preventing it from looking too odd as wrapping occurs.

We then stop having #extras be next to the content, and instead split it into two floated columns using those nice .firstHalf and .secondHalf div we prepared. Again I use a negative margin on .secondHalf to make sure we don't have "perfect width float drop", making the second one narrower in flow. As it's floated left, it does not change position or size if we make the margin-right negative. I decrease the margin on the .subsection so we have more screen space to fit content into, and then adjust content the same way as it's no longer a separate column and instead is shown below #extras... which is why I put the border on all corners too.

A final tweak is to split the footer into separate lines and lose the bullet.

@media (max-width:35em) -- we get down this narrow things get tricky. We strip off columns ENTIRELY by removing the floats, margins and rounded corners. We need space for content, so start stripping off the fancy crap.

I adjust the alignment of the H2 so I can put some controls to hide/show the menu and contactInfo sections as on mobile, having them open pushes the content section way down the page annoying users. Most people use a mess of javascript to do what I'm about to cover, but thanks to CSS 3 we have the ':target' pseudo which can let us do this in far, FAR less code.

First we hide the child "#mainMenu ul" and "#contactinfo div" with display:none, then we make a :target state on thier parent ID's to say show them with display:block; Those anchors in the markup target #mainMenu, #contactInfo or # -- you click on one that has the ID hash, it will show the menu. You click on the close one to go to the null hash, it will hide it.

.closeId and .openId get some nice style and floated next to the H2 text, as well as some purty hover states. We the use display:none and display:inline-block to show/hide them as needed since close should be hidden when it's closed, and open should be hidden when it's open. I then use generated content :before to plug in the text. I do this so that the anchors aren't seen and aren't really even rendered when we're not using this media query.

... and boom, with four empty anchors in the markup and less than 1k of CSS, we've replicated what people waste bloated idiocy like jquery and tens of k more scripting on doing... and we have real text instead of some vague icon that christmas only knows what it means.

@media (max-width:30em) the narrowest target, we make the H1 text smaller to fit, stop forcing the span inside #tagAndPhone to not wordwrap as we don't have the room to be picky about that, and we strip the padding off our fieldset and adjust the labels to show over the inputs instead of next to them.


... and that's the CSS.

Content > Semantic Markup > Base CSS Screen media Layout adding DIV/SPAN only when needed > Media Queries.

It's called progressive enhancement, and it makes the page VERY well behaved if/when (mostly when) the fancy bits are disabled, blocked or otherwise unavailable.

Now, I know this whole thing is going to be a lot to take in, but that's how things should be done these days. Take your time, soak it in, any questions hit me with your best shot.

Hope all this helps.