Which looks better?

Option 1
Option 2

Does it look better with or without the blue line under the title of the page.

 

Personally, I like it with the line. It can of ads to the page while separating the text sizes, so I like it with better.

 

I don't like the giant dotted line, I don't like the massive text size of the heading, I don't like the hard to read webfont on the flow paragraphs, can't say I much care for the inconsistent padding and margins, the utter and complete destruction of accessibility by declaring font-size:16px on body, much less the inaccessible images for text, or the painfully useless thin-glyph webfont with insufficient colour contrast...

Nope, can't say I like it, can't say I like it one bit... Either way.

 

"inconsistent padding and margins" ... Where are there inconsistent padding and margins?
"declaring font-size: 16px on body" ... Temporary until I get everything looking the way I like, that way I can easily adjust styling without having to clear my browser's cache every time I want to see a change
"inaccessible images for text" Something I planned on switching in the near future, just haven't quite got around to doing so yet
"massive size of heading" Yeah you're right, I reduced it by a fair margin, I think it looks better now
"giant dotted line" "painfully useless thin-glyph web font" What do you propose as alternatives?

 

with blue line is much better

 

with blue line is better

 

I prefer without the blue line. There is already a line at the bottom of the header, one more line below the title makes it a bit unpleasant. By the way, I would make the width of the content area narrower. It's usually hard to read page-wide text on websites.

 

The gaps above/below the menu/logo don't match, the gap between the menu and the first sub-heading is way bigger than the gap after the paragraphs, the gap between the paragraphs seems to be a fraction what it should be... and the footer has WAY more padding top/bottom than anything else.

Not sure what disabling EM's default behavior has to do with caching behaviors -- since you're forcing ALL fonts on the page to ignore the system metric and why we've been told almost since CSS was introduced to use % or EM for font-size... and why using EM for any declared widths, paddings, etc, is a desirable behavior. (aka "elastic" layout). You basically just took a dump on accessibility with that. (unless you're saying you ALSO manually test it at 20px... and 24px -- then switch it to either 1EM or 100% for deployment)

To me that reeks of having dicked around in photoshop before you had content or semantic markup of same. Photoshop is NOT a design tool no matter how many ignorant halfwits and outright sleazy scam artists claim otherwise.

As I will keep telling people, start out with your TEXT in a flat text editor as if HTML didn't even exists and arrange it in a logical order. You then mark up that content semantically paying no heed to the default appearance of the tags since that's NOT what HTML is for, then bend that HTML to your will with CSS to apply layoutS for different media targets to it. (yes, PLURAL). Said layouts should be elastic (based in EM), semi-fluid (having a max and possibly a min-width), and responsive.Then and only then start playing with colours, borders and other presentational affectations like hanging presentational images on it.

To me that you even have images with what should be flow text in them means you started out in the wrong tool with a completely back-assward approach to making a website -- at least if you care at all about visitors actually finding the site useful.

I prefer it without the line -- though having the divider go full width looks better than what you had before -- would probably look even better if the gap above and below said line matched.

As to the webfonts, they're a cute toy that should be used with an eyedropper for things like headings -- but since most of them lack hinting information allowing the glyphs to be hammered into pixel boundaries and in the case of what you have, the result is such painfully thin glyphs that your colour contrast (or lack therein) ends up HALF what it should be. For flow paragraphs stick to the safe well known system font stacks, like "arial,helvetica,sans-serif". Other safe system fonts like "Segoe UI" or "Tahoma" aren't anywhere near as bad as that "openSans" rubbish.

Webfonts for flow text is a waste of bandwidth, has severe legibility concerns, inconsistent rendering cross-browser, endless sizing, spacing and offset woes, and on the whole should be considered a failed technology from an accessibility standpoint. That developers are now pissing all over the functionality and speed of websites with this garbage, well... I just don't get it.

Well, that's not entirely true -- I'm starting to get it; it's confirmation of something I learned decades ago. "Graphic artists" (I'm using that term, I have a much more offensive one in my head) HATE legible fonts, and will nitpick good clear fonts to death looking for flaws or cop-outs like arial's "Ill" issue (cap i and two lower case L) - to justify their goofy, illegible, and ultimately useless artsy-fartsy BS.

Much like back in the early 1990's where a lady friend in college was part of the schools stage troupe, and the head of the graphics department at the school designed a logo for T-Shirts for them... that were a waste of money and few were bought as nobody could figure out what the blue blazes a "Gomuddy Grueue" was. The script was so ridiculously ornate and illegible that it was allegedly supposed to say "Comedy Crew" was utter and complete BULL.

For flow text -- aka normal grammatical paragraphs -- do the world a favor, and stay away from webfonts. ALL OF THEM. You're just making life harder for visitors to your site.

Likewise you might want to familiarize yourself with the WCAG, in particular the parts about legible colour contrasts. This online tool:
http://webaim.org/resources/contrastchecker/

Is slightly off, but close enough for most tasks and one of the better ones since it tells you if your foreground and background meet WCAG 2.0 AA and AAA compliance. When possible TRY to meet AAA, and consider AA to be the "bare minimum". By WCAG 1 math your #777 on #FFF would be considered bare minimum, under 2.0 it would only pass AA as a really large or bold font, and even as normal Arial (which is far thicker than that webfont) would fail as AA, much less AAA. That really thin glyph crappy poorly rendering webfont (that probably only looks good on a quackintosh or other crApple product) reduces the ACTUAL render color all the way down to #D2AD8A under cleartype -- that would fail BOTH AA and AAA for large font sizes.

... and again that's before we take the lack of auto-enlargement for large font/120dpi or users of other non-standard defaults into account.

Also that's before we talk the relative lack of semantics or logical document structure in the markup -- which again reeks of worrying more about what it looks like than actually using HTML properly... the bold tags doing H3's job, static style inlined in the markup, attributes like ALIGN that have no business on any website written after 1997, clearfix nonsense like it's still 2003, IMG tag doing text inside a H1's job, HTML 5 code bloat for nothing (those 'new' structural tags, pointless redundancies at BEST, presentational markup at worst!), garbage data- attributes for no legitimate reason, broken viewport meta disabling zoom (way to piss off visitors even further), and the pointless scripttardery on a page that by all accounts shouldn't even have scripting. You don't even have logical document structure or completed markup -- but your already throwing style at it?!?

... or even the stupid malfing sticky header garbage wasting screen space better used to show why the visitor came to the page in the first place -- to see the CONTENT.

Finally -- Sniff... sniff.... do I smell bootcrap? Do yourself a favor, go find a stick to scrape that off with before tracking it all over the Internet's carpets. Much like all the other mouth-breathing halfwit framework BS the only thing you can learn from bootcrap is how NOT to build a website.

From time to time I do complete rewrites of what people are working on just to illustrate what I'm talking about -- these are small simple pages, so it should take little if any time to do such a rewrite.

If I were writing the same page, the markup would probably go something like this:

<!DOCTYPE html><html lang="en"><head><meta charset="utf-8">

<meta
	name="viewport"
	content="width=device-width, height=device-height, initial-scale=1"
>

<meta
	name="description"
	content="Learn how to Become an Actuary Today!"
>

<meta
	name="keywords"
	content="actuary,exams,casualty,society,credits,insurance"
>

<link
	rel="shortcut icon"
	href="favicon.ico"
>

<link
	rel="stylesheet"
	type="text/css"
	href="screen.css"
	media="screen,projection,tv"
>

<title>Become an Actuary - ActuaryExams.com</title>

</head><body>

<div id="top"><div class="widthWrapper">
	
	<h1><a href="/">Actuary Exams</a></h1>
	
	<div id="mainMenu">
		<a href="#mainMenu" class="showMenu"></a>
		<a href="#" class="hideMenu"></a>
		<ul>
			<li><a href="Actuary-Information.php">Become an Actuary</a></li>
			<li><a href="Study-Books.php">Study Books</a> </li>
			<li><a href="Practice-Questions.php">Practice Questions</a></li>
			<li><a href="Exam-Schedule.php">Exam Schedule</a></li>
			<li><a href="Exam-Statistics.php">Statistics</a></li>
			<li><a href="Actuary-FAQs.php">FAQs</a></li>
		</ul>
	<!-- #mainMenu --></div>
	
<!-- .widthWrapper, #top --></div></div>

<div id="content"><div class="widthWrapper">

	<h2>Become an Actuary</h2>

	<p>
		Candidates who do well in the actuarial profession usually have one of two backgrounds after graduating in college: a solid understanding of business/finance, meaning people who graduated with degrees in <b>Finance</b>, <b>Economics</b>, <b>Business</b> or <b>Accounting</b>, or a strong analytical background like those who have degrees in <b>Mathematics</b> or <b>Statistics</b> and even those who have graduated with degrees in science that use a lot of math or critical thinking skills. However, like many career paths, entering the field of actuarial science isn’t as simple as graduating from college with a relevant degree. Insurance companies that hire actuaries are looking for candidates that have credentials or are on the path to obtaining credentials in the field. In the United States there are two societies through which those aspiring to be an actuary must take exams in order to obtain credentials, the Society of Actuaries (SOA) and the Casualty Actuarial Society. While there are some differences in the types of actuaries that come from each society and the process to become credentialed in each society the preliminary portion of the process is more or less the same.
	</p><p>
		Despite having a few differences the CAS and the SOA both have two different levels be being accredited to do actuarial work, an associate (ASA for SOA, ACAS for CAS) and a fellow (FSA for SOA, FCAS for CAS). To become an associate through either society one must pass a series of preliminary exams each specializing on a specific topic, in addition the exams there are online courses that must be completed, VEE credits (which can be obtained through college classes or passage of additional exams) and a course in professionalism. To become a fellow through either society additional exams must be completed, through the SOA those who wish to become a fellow must pick a specific “track” and set of exams to take that focus on one area of insurance. Below are tables outlining the specific requirements for each society.
	</p>
	
	<!--
		what follows is actually tabular data, just look at the semantic
		relationships! Of course, that's gonna inhale up on the proverbial
		equine of short stature when it comes time to make this mobile friendly.
		
		The ID is there so these subsections can be directly linked with a hash
		if desired.
	-->

	<table class="requirements" id="ASA_Requirements">
		<caption>ASA Requirements</caption>
		<thead>
			<tr>
				<th scope="col">Requirement</th>
				<th scope="col">Description</th>
			</tr>
		</thead><tbody>
			<tr>
				<th scope="row">Exam P (Probability)</th>
				<td>Pass exam P through SOA or exam 1 through CAS</td>
			</tr><tr>
				<th scope="row">Exam FM (Financial Mathematics)</th>
				<td>Pass exam FM through SOA or exam 2 through CAS</td>
			</tr><tr>
				<th scope="row">Exam MLC (Life Contingencies)</th>
				<td>Pass exam MLC through SOA</td>
			</tr><tr>
				<th scope="row">Exam MFE (Models for Financial Economics)</th>
				<td>Pass exam MFE through SOA or exam 3 through CAS</td>
			</tr>
		</tbody>
	</table>
		
	<table class="requirements" id="ACAS_Requirements">
		<caption>ACAS Requirements</caption>
		<thead>
			<tr>
				<th scope="col">Requirement</th>
				<th scope="col">Description</th>
			</tr>
		</thead><tbody>
			<tr>
				<th scope="row">Exam 1 (Probability)</th>
				<td>Pass exam P through SOA or exam 1 through CAS</td>
			</tr><tr>
				<th scope="row">Exam 2 (Financial Mathematics)</th>
				<td>Pass exam FM through SOA or exam 2 through CAS</td>
			</tr><tr>
				<th scope="row">Exam 3 (Models for Financial Economics)</th>
				<td>Pass exam MFE through SOA or exam 3 through CAS</td>
			</tr>
		</tbody>
	</table>
		
	<p>
		Although there are quite a few exams required to become credentialed in addition to online courses, VEE credits and professionalism courses you don’t need to have passed all of them (or even a decent amount of them) to get hired by an insurance company to do actuarial work. Internship positions within actuary departments hire candidates with anywhere from 0 to 2 exams passed and full-time positions usually look for 2 or more (though in some rare instances candidates with less exams passed will be taken). Many companies hire on candidates that have proven that they can do well on the exams as it is an important part of becoming an actuary and will pay exam fees, purchase you exam study materials and will give you paid study time to ensure you do well on the exams and don’t have to suffer the financial burden of everything that goes along with taking the exams. Some companies even offer raises for every exam passed and one-time bonuses for passing an exam on your first attempt.
	</p><p>
		While the path to becoming an actuary may seem difficult and time-consuming it is well worth the work that is put into it, actuaries are very well compensated some obtaining a six figure salary within five years of getting a job, it should also be noted that the actuarial profession is consistently rated highly in terms of job satisfaction amongst all other jobs. All things considered if you have the degree of analytical thinking necessary to pass the exams and the patience and dedication to commit to them, you could gain entrance into a career field that allows you to use your critical thinking skills, work in a low-stress environment, have overall high job satisfaction and be compensated very well while not working too many hours per week.
	</p>
	
<!-- .widthWrapper, #content --></div></div>

<div id="footer">
	<hr>
	<div><span>Actuary</span> Exams</div>
	Contents &copy; Actuary-Exams.com unless otherwise noted
<!-- #footer --></div>

</body></html>

Code (markup):

It is unlikely in what you've done (or conceivably even what you are doing) I'd even be throwing scripttardery at that -- Gimme a few and I'll belt out the CSS I'd use to style that... then a breakdown of the HTML and CSS to explain the how/what/why.

 

I like it with the blue line for emphasis. Just a note though that if you put tables on the website make sure that the texts inside them are large enough for visitors to see them. Just a suggestion.

 

... and here's that rewrite, no changes to the markup I posted this morning. CSS didnae take long.

http://www.cutcodedown.com/for_others/Pudge1/actuary/template.html

AS with all my examples the directory:

http://www.cutcodedown.com/for_others/Pudge1/actuary/

Is wide open for easy access to the bits and pieces... which are pretty simple.

It uses actual semantic markup with a logical document structure (like one and only one h1 under which EVERYTHING on the page is a subsection, HR to indicate change in topic/section where text is unwanted/unwarranted, NOT just because I want a line across the screen)

Elastic design with as much flow text as possible in EM's -- the only excuse of PX measurements being on the H1 under the logo. As I used generated content really old versions of IE won't get the logo; OH WELL. You really care put some sandbag spans in there and use those as the gilder-levin targets. Since it uses gilder-levin it gracefully degrades images disabled, and I made it semi-fluid with a max-width so that long paragraphs are less difficult to read. (Suggestion: I'd REALLY try to fill up a sidebar with some stuff to help make it less of a 'crappy little stripe' on large displays).

Of course I also made it responsive, adjusting the layout to fit the screen for smaller devices, shove a fixed width at legacy browsers that can't handle min/max-width (basically IE6/earlier, this page should work all the way back to IE 5.5 in it's current form). This includes hiding the menu at really small display sizes but instead of the uselessly vague "hamburger icon" crap and the pursuant scripttardery, I leverage CSS3's capabilities and put actual meaningful TEXT there.

Believe it or not, the entire page is nothing but Arial -- yes, even the flow paragraphs. It's shocking what 1px of letter-spacing can do. I upped the line-height even further for larger displays, but drop it back down to 150% as the display size shrinks -- likewise I reduce the side padding as the window size dwindles to use up more of the available screen space.

IF I were to use the line (I personally wouldn't) I'd add it as bottom-border to the H2, adding a bottom margin that's the same as the bottom-padding on that element so the spacing is consistent.

Gimme a bit and I'll write up a breakdown of the how/what/why of the HTML, to be followed shortly by the same for the CSS. I probably won't start in on that until after dinner.

 

Alright, to break down the reasoning for the HTML rewrite:

I like to put the doctype, html, head and charset meta on the first line together as a reminder that NOTHING should go between those elements, and that the charset should be declared as early in the code as possible. (you don't get much earlier than that). That way if you want UTF-8 and the HTTP header for that is missing, you don't force a reflow when the browser comes to it after content.

In the same way I keep </head><body> and </body></html> together as further reminders "Nothing belongs between those tags" -- too often nubes will get hold of a page you've written and just start willy-nilly pasting in code anywhere; this reduces the odds of them putting it in the wrong place.

You'll notice I like carriage returns in tags with lots of attributes, I just find it easier to read and to quickly see what values are declared.

The "viewport" META I do NOT set "maximum scale" or "user-scalable" like you did, since those DISABLE ZOOM -- way to piss off mobile and accessibility users. I do add "height=device-height" as some Android browsers will incorrectly report their "lie" height as width when rotated into landscape.

The "description" META I threw in there to divide up the excessively long and less than useful TITLE tag you had. Really it should be a bit more verbose and natural language than what's there. Remember, the sole reason META[description] exists is to be the text shown under the link to the page on a SERP.

"keywords" META I also added picking words from inside BODY that seemed the most important. The entire reason this META exists is to list seven or eight single words that exist inside <body></body> that you want a slight upranking for. That's why it's called keyWORDS and not keyphrases or keysentences... keyWORDS! Preferably totalling 127 or less characters (some people say 95 or less!). You vary from that recipe, it will either be ignored, or even get you slapped down for abuse. Hence why the massive disasters some people sleaze into this META are just mind-numbingly dumbass!

Switching to a proper .ico deals with that not all browsers can even do a .png there. Adding "shortcut" to the REL attribute also increases the number of browsers that will pay attention to it. I also HIGHLY suggest that you put that favicon.ico in the same directory as the markup is being served from, otherwise you'll find a LOT of 404's from UA's that skip trying to read this <link> -- there are still a number of browsers in use that just look for it there as "favicon.ico" completely ignoring that the <link> even exists.

The stylesheet LINK I added all the missing properties like TYPE and MEDIA. The MEDIA values I use now throw an error in the HTML 5 validator, but since said validator is uselessly full of **** I wrote it to the HMTL 4.01 spec and validated there, only slapping the 5 doctype on it for deployment. There are STILL a LOT of devices out there that use "projection" in full screen operation or report themselves as "TV" instead of screen, or worse if you don't say "TV" try to apply their own changes to the style. (just more HTML 5 asshattery with them removing that, whilst claiming their inclusions of crap like "embed" is about documenting what people are doing...)

The TITLE I always put the current page description BEFORE the site title. This way if you have multiple tabs of the same site open, you can tell them apart from the text in the tab or taskbar or what-have-you.

Getting out of HEAD and into BODY, I use a double-wrapping DIV since you seem to have the subsections of the page full width with a constrained width inside them. Seems wasteful, but since DIV is a hook for presentation without saying what that presentation is, this does not qualify as "DIV for nothing".

I do NOT use the allegedly semantic and ultimately presentational asshattery of HEADER, FOOTER, NAV, SECTION or ARTICLE because IMHO those tags exists for NO legitimate reason -- numbered headings, captions, legends, labels and horizontal rules were supposed to provide that functionality from the day HTML was created, and STILL few people even bother trying to use those properly -- nor have many browser makers bothered implementing that functionality; and now we're supposed to magically believe they're going to make those do something when NOT ONE SINGLE UA ACTALLY BOTHERS TREATING THEM AS ANYTHING MORE THAN A DIV? I'm increasingly holding the same opinion of Aria roles, pointless code bloat no legitimate UA has any reason to do anything with!

You'll also notice my commenting style. I like to add comments to say what DIV I'm closing, but there's a problem where comments (the things browsers are supposed to ignore) between positioned flow elements can trigger rendering bugs in legacy IE and like every other blasted build of Firefox. (In the latter's case I've never seen "fixed" bugs re-appear every other release with the frequency Mozilla manages). Putting the comment before the closing tag prevents them from ever ending up between elements that might recieve floats, positioning or other "triggers" for bugs like "disappearing content" or "double render" -- bugs that if you DO encounter can drive you batty and reduce the amount of hair atop one's head.

I also find using this commenting style makes it easier to find the end of things when scrolling -- but I don't tend to use colour syntax highlighting as I find it an illegible acid trip.

I call the first one #top so that if you decide later to add a <a href="#top">back to top</a> type link later on, the hook is already in place. For the same reason the content area is marked as #content.

You'll notice the DIV.widthWrapper gets reused, it's just there to constrain the width and center that constrained area.

The H1 is the heading under which EVERYTHING on the page is a subsection -- it's the glue that ties together EVERY page on the site, which is why the name of the site is the best content for it. You want a logo there, use gilder-levin to hide the text under the logo. Images off, you get the text -- it gives search engines something to look at, it's just logical document structure.

DIV#mainMenu - normally I rail against the use of "div for nothing" around UL, which are perfectly good block level containers unto themselves -- but see those two empty anchors that follow? Those allow us to use :target to show/hide the UL inside this DIV - so that's NOT DIV for nothing.

In your original you had endless presentational classes, DIV when you had a NAV, I just didn't see what all that was even for other than bootcrap being smeared all over the markup.

We close out the .widthWrapper and #top and we're into #content and it's .widthWrapper

Like yours I pretty much have a H2, but in this case it's VALID since how can you structurally have a H2 without a H1 preceding it? (since a H2 marks the start of a subsection of the H1, that's what it MEANS, it does NOT mean "make bigger text"!). I do not waste time with any extra DIV and classes for NOTHING around the paragraphs, nor do I use inline STYLE. General rule of thumb, if you are using the STYLE attribute in all but the rarest of cases you are doing something WRONG -- in EVERY case if you use the <style> tag, you ARE ALWAYS doing something wrong. It's called separation of presentation from content and should be practiced during the ENTIRE development cycle. Otherwise you're just making more work for yourself!

I retained the bold tags there since those are titles and not recieving emphasis. Some people would say those should be STRONG tags, don't believe it. <strong>You're not adding "more emphasis" to that text.</strong>

I coded up the first three to four rows of your first two tabular areas -- some people will balk at the use of tables, but to be frank that IS tabular data! You've got a caption before them, obvious columns with headers; so that's TH in THEAD with SCOPE to say what direction the TH are declared for... and each row has a topic and explanation -- so that's a TH with SCOPE saying they are for the row, and TD for the data.

It's actually laughable how few people seem to realize there are more tags that belong in a table than just TR and TD, much less how many people are just making up BS about "never use tables" -- if it's tabular data, that's what tables are FOR! It's tables just for layout purposes that's the problem.

From there it's just more paragraphs... we close out .widthWrapper and #content, and it's on to #footer.

Since the #footer content is so tiny I didn't even bother adding a DIV.widthWrapper to it. The horizontal rule inside it is there to say "this is NOT part of the heading before it" since that's what a HR means -- it does NOT mean "draw a line across the screen" even if that's the default behavior!!! In professional writing a horizontal rule could be anything from a string of three asterisks, to a centered elipsis, to a page feed.

Remember, if you choose your tags based on their appearance instead of their meaning, you're choosing all the wrong tags for all the wrong reasons. That's why all those bits of idiocy from HTML 3.2 like CENTER, FONT and BORDER were supposed to go the way of the dodo 17 years ago. It's also why using the STYLE attribute or worse, <style> tag are just outright rubbish. (there are maybe TWO exceptions when it comes to the attribute).

I used classless DIV and SPAN as that text really doesn't feel like it should be a heading, there's not enough text to call it a paragraph since it's a incomplete thought, and since there's not a lot going on there we can inherit off the parent #footer instead of wasting time throwing classes at everything.

From there it's just a matter of closing out the document. It validates HTML 5 apart from the "projection,tv" part of the CSS <link>, and would validate 4 STRICT if not for the charset meta... Way to go W3C making 5 validation even LESS useful!

Alright, I'll get started on explaining the CSS.

 

Ok, on to the CSS:

I always try to go with a single monolithic stylesheet per media target per SITE. The reasoning for this is:

1) An entire website should not need more than 48k of CSS apart from developer ineptitude -- and when I say that I mean UNCOMPRESSED. If you have ANY clue what you are doing, that's about the upper limit you shoudl ever need -- hence why massive train wrecks of stupidity like bootcrap starting out as TWICE that before you've even written your own style (that then results in bigger bloated markup thanks to endless pointless presentational classes) are, well... massive bloated train wrecks of stupidity.

2) The more separate files you have, the more handshakes and the slower the page will load. Again a strike against frameworks since most of them tell you to load their crap separately with <link>. Remember that past the first 8 files on a site you can expect an average of a fifth of a second up to a worst case of a second or more overhead for each additional file REGARDLESS OF CONNECTION SPEED! Less files you use, the better!

3) If you load the entire sites CSS first, you can leverage caching on non-bounce users when they load subpages. It makes navigating around the site faster, smoother and more enjoyable to the visitor.

In my stylesheets I always start out with a "reset". Resets exist because HTML does NOT actually specify the default appearance of tags -- this was intentional as appearance is not nor was ever meant to be HTML's job... It's just that Nutscrape and Microshaft during their one-upmanship pissing war dragged it away from the original intent. That intent being to say what thigns ARE or WOULD BE in a professionally written document so that the user agent (aka browser) could best determine how to convey those meanings. You want to customize those meanings, that's the job of a stylesheet. (should be noted TBL's original "browser" actually had what today would be called "user stylesheets")

Because the spec is uselessly vague on the topic, you cannot reliably expect consistent margins, paddings or borders. A good reset declares a consistent baseline so you don't have to say those values each and every blasted time you want to use elements that may have different defaults.

There are smaller resets like the so called "universal" one of "* { margin:0; padding:0; border:0; }" but that can make styling form elements between IE and FF a royal pain in the arse. There are bigger resets like Eric Meyer's "Reset Reloaded" but that wastes time and code declaring things that aren't even inconsistent across browsers, that you'd probably just redeclare anyways, and honestly borders on being a framework unto itself. ... and you should have a pretty good idea of my opinion of frameworks by now.

The one I use (developed by Dan Schulz shortly before he passed away) is a nice safe middle-ground. At a quarter of a K it's not so massive as to be a bandwidth worry, and it hits JUST what needs to be hit.

In terms of layout I always start with the lowest common denominator -- a LOT of people say that's mobile, and they're WRONG! Mobile we can target with media queries to customize it, what can't we target that way? Legacy desktop browsers... so for me, IE8/earlier is my starting point for layout and then I use the media queries to make it mobile friendly.

HR -- I hide the HR as they are in my code for semantics, NOT to draw lines across the screen. Drawing lines / dividers is BORDER's job.

-text-size-adjust -- This like the viewport meta tells certain browsers we know what the **** we are doing and to leave our text sizes the hell alone! Sadly if you sent this to desktop versions of Safari it breaks zooming, but you really only need to send it to older iPhone / iPod devices of 480px or narrower width (or more specifically their LYING about width). There are a handful of Windows devices that have this same failing hence the -ms prefixed version. Thankfully that bit of asshattery has gone the way of the dodo on modern devices, but it's a good idea to include it "just to be sure". Not everyone can afford a new phone every six months!

body -- I set the min-width on body for legacy browsers that can't do media queries; basically IE 7 and 8. This prevents the layout from breaking on those desktop targets.

We align a lot of things center so might as well say it here -- this also lets us center all the .widthWrappers in IE5.x -- NOT that we really should give a flying **** about anything older than IE7, but in total there's maybe a 200 bytes used in the stylesheet and methodology that can make it work back to then, so ... why not?

I always declare the font most used on the page on BODY. 85% of arial is usually pretty good for sites; It's pretty hard to go wrong with it. WHENEVER you declare a font-size change declare the line-height as you cannot trust inheritance across different browsers. (The lie being fed from the tablecloth on some other forums about omitting the metric and having it inherit is 100% grade A farm fresh manure, no matter how vehemently some people defend the practice). Since by the time you say font-size and line-height separately you're at almost as many characters as the condensed font declaration, I just say go ahead and use the condensed font declaration EVERY time you change the font-size. It just makes the code clearer as to what's being set.

I went with the taller line-height to furhter increase clarity due to the really long lines and lack of sidebar to use up the screen space.

I also set the background color as you cannot rely on white being the default either. Sounds silly, but it's true. I darkened the flow text to #555 as that's really the minimum for non-bold "normal size" fonts for WCAG 2.0 AAA compliance. (technically #595959 is the min, #555 is "close enough")

.widthWrapper -- I set overflow and a haslayout trigger just in case you decide to have floats inside the various areas. The max width of 56em was chosen as the point at which the long paragraph lines JUST start to get hard to follow. The auto margin provides centering of these elements in modern browsers.

* html .widthWrapper -- IE6/earlier can't handle min or max-width, so just feed them a fixed width. The comment there says it all -- OH WELL! That we even BOTHER at this point...

#top -- I set relative positioning to absolute position the H1 inside it. Usually I hate doing aPo on what should be a flow element, but with the image replacement method in place and wanting it centered consistently at the middle, it's really the best way to go. Again we use zoom:1 to trip haslayout fixing legacy IE positioning bugs. The right text-align will push our inline-level menu items to the right, from there it's just padding and border.

h1 -- absolute positioned 50% from the top and the using a negative margin equal to half it's content height will center this top to bottom in #top. There's a bug where font-size can screw with us in some browsers if we declare px fonts inside the anchor (or worse on the H1) so we say font-size:100% to make sure if we want EM's or if that bug arises we can do so worry free.

h1 a -- setting this to display:block lets us set the top and bottom padding. 20px of padding + 36px of line-height == our desired 56px of logo image height... without declaring "height". good rule of thumb, if your element is NOT an image container, declaring height is sloppy and will likely just bite you.

h1 a:before -- generated content to show the logo. The NON-TRANSPARENT logo image (try to avoid using alpha transparency on images!) will hide the text with the logo when the images are showing, but reveal the text images disabled. On SOME responsive layouts you may want to do away with the logo entirely, generatiing it from the CSS is just a better approach. really old versions of IE won't do generated content, so if you care about them getting the logo put a empty span inside the h1 and target that instead. This is called "Gilder-Levin Image replacement" and is one of the few image replacement methods worth a flying purple fish.

#mainMenu -- the wrapping div we float:right as in some of the media queries we may restrict it's width narrower than the screen width.

#mainMenu a --We hide all the anchors (mostly just to get rid of .showMenu and .hideMenu) to then later turn them on for the ones inside the UL. the top/bottom padding is half the logo height, providing enough room to be sure the logo isn't cut off. I also turn off underscores and set the colours and hover states at this point.

Notice that I target :active and :focus in addition to :hover -- :focus is supposed to be for keyboard navigation, but some older browsers incorrectly use :active (meaning it's been clicked on or "launched") instead. You're usually best off just declaring all three.

#mainMenu ul -- turn off bullets -- yawn.

#mainMenu li -- when possible I try to use inline on LI and inine-block on anchors for menus, its' just easier to push them around and avoids bugs like IE8's dreaded "staircase floats". Good rule of thumb, make the LI display:inline and then as much as possible avoid trying to do anything with them. Mind you, if you want dropdown menus that's when you are forced to style them, but that's just another reason (alongside how suckastic they are on mobile) that I've pulled the plug on even having dropdowns/flyouts on websites I make.

#mainMenu ul a -- inline-block makes JUST the anchors inside the UL show, while letting us declare things like heights or paddings if desired. Left margin just pushes them apart.

H2 -- padding, font-size, color, yawn. Note that 0.5em would be 1em elsewhere on the document since we declare the font-size as 200%.

p -- I went with a much lower text-indent; you were using percentage which in your case was based on screen width, so on large screens that twenty character indent looked really stupid. 2EM is about the upper limit I'd use for that, though to be frank most "modern" document style guides say to not indent paragraphs anymore unless you're writing a novel. I'd consider getting rid of the indent altogether. Good rule of thumb, the ONLY place it's really safe to declare % is on font-size, and occasionally width.

I use bottom padding instead of margin on paragraphs so as to avoid margin-collapse headaches, and I usually go with a bottom padding a hair shorter than the line-height to account for the line-heights own gap. In this case 1.5em seems "about right" and we'll use that same value on other elements like the tables.

Finally I added 1px of letter-spacing to really change up the appearance of plain-Jane Arial. It's actually funny how such a simple change can make it look so different.

#content -- padding the sides and the top. The leading element of this section (typically a h2) will have a larger line-height (even if we declare it the 120% minimum) so we want the top padding about half an EM shorter than what we put on the bottom. (a value some people fail to take into account). We also put the text-align back to left since that's what most of this content will be.

.requirements -- The various little tables. The 100% width will force it to expand to fit the screen, but the max-width will make it not go so wide as to be hard to follow. Border-collapse:collapse has much the same effect as cellpadding="0" cellspacing="0" would in the markup (damned handy to know!) and of course the margin centers it. Border in the CSS declares only the outer-border and not that between cells.

.requirements caption -- the caption just needed padding and I made the text bigger in additon to being bold to make it clearer that it's a heading, and not just some text thrown in there.

.requirements th,
.requirements td -- we want them all centered. Chrome for some reason on TH will inherit instead of remaining centered if the parent has text-align:left, so we really have to say that on TH as well as TD.

.requirements thead th -- heading titles get a larger font-size and some colouration. Nothign too fancy -- again remember to do the math, as at 125% font-size 0.2em and 0.4em would be the same as 0.25em and 0.5em elsewhere on the page!

.requirements tbody tr th,
.requirements tbody tr td -- I set the font-weight to normal on both just so I didn't have to make a separate declaration just for the TH. an even half EM padding all-around makes it clearer each part is a separate declaration/row... from there it's just background-color.

.requirements tbody tr:nth-child(even) th,
.requirements tbody tr:nth-child(even) td -- using nth-child we can make every-other row have an alternating background. This does not work in really old browsers, OH WELL -- it's a cute presentational effect, NOT essential to the usability of the page.

#footer -- padding, color, background, yawn.

#footer div -- a bit of padding on the larger site name text, bigger font, and letter-spacing to widen it slightly.

#footer div span -- ooh, BOLD... :/

... and that's the desktop layout for both modern and legacy browser support, from there it's just a matter of using media queries to customize it for small screen and modern devices.

----------------------------------

When choosing my media query widths I just narrow the window until the layout breaks, then use that width to make the fixes. I test in both large (120dpi) and small (96dpi) settings in different browsers to make sure the layout is stable in both -- this is why my media query breakpoints are typically in EM so that the layout and it's breakpoints remains elastic.

@media (max-width:54em) -- we start out lowering the min-width on body since at this point we know we can adjust the layout to be freindly down to that small. 192px is realistically the smallest device you are ever likely to encounter, so that seems a good starting spot. (anything smaller will NOT be obeying the screen stylesheet anyways). I then reduce the line-height to make more stuff fit on the page -- since the paragraphs would be narrower anyways we don't need it as tall for legibility. I increase the padding and margins on the anchors so that they are "finger sized" targets (google's mobile friendly will check for that!), and set them up not to wrap internally since that too can cause... problems.

with #top, #content and #footer I decrease the side paddings to half an EM to also make more room for content, and adjust the size of the H2 down smaller as well for the same reason.

@media (max-width:50em) -- at this next breakpoint "FAQs" dropping down to it's own line looked stupid, so I change out the padding and set a max-width on the menu to split it into two somewhat more even lines.

@media (max-width:32em) -- final media query we make even more changes. Stripping padding off #top we swap out the positioning on h1 to best fit next to .showMenu and .hideMenu. We strip the float off #mainMenu so it goes back to filling the available width and stripping off the max-width. Setting up float clearing on the UL pushes it below .showMenu and .hideMenu (and therein the h1), letting us then set up padding on those to fill the needed height.

The real "magic" here is the games we can play with display:none and display:block with the new CSS3 :target attribute. Since we're in a media query we can be sure this will work for what we're targeting, and it lest us implement the mobile "menu hiding" WITHOUT any scripttardery.

First we set the UL, the normal .hideMenu and :target .showMenu to display:none -- this hides the menu, the "hide menu" button, and the show menu button when the outer div is targeted by a hash.

Then we set the :target UL and :target .hideMenu to block making them show when #mainMenu is targeted by a hash in the URI. Boom, instant show/hide just by leveraging anchors.

I use generated content to plug in the text (and utf-8 geometric shapes) of those anchors, so they can be in the markup without that text for CSS off and other times where those elements serve no legitimate purpose.

I also take the time to pull the text-indent and letter-spacing off the paragraphs to try and squeeze more text into the smaller screen space.

... and that's how I'd have done the CSS for that same page concept.

I know between these posts that's a LOT to take in, but you had so many flawed approaches and methods I thought it might be a good idea to show you how it should be done. It SEEMS like you were starting around playing with images instead of focusing on content as content FIRST; there is far more to a website than what it happens to look like at a specific dpi specific font size screen layout -- there are stepping stones to accessibility and if you want to make a useful site, one would do well to pay heed to that.

Sadly, too many people have become so obsesses on what it looks like in front of them, they lose sight of the notion that what you see is pretty much guaranteed NOT to be what everyone else gets. That's why you test different resolutions, different browsers, different default font sizes (be it browser or OS set), and practice all the good concepts we've been told to do like progressive enhancement and separation of presentation from content.

Hoping this helps and doesn't just get glossed over -- you seem to have some good instincts for design, you just need some help getting your semantics and accessibility mindset worked in your flow.

 

Wow, thank you. Your new design looks so much cleaner than what I was previously using. Beyond that you offered a lot of insightful advice on how to improve future layouts. I'll have to read this over a few times just to take it all in.

Thanks again, I really appreciate it!

 

Its looks good with the blue line, but if you make it as on sky blue or light blue means much better...

 

Hi, I think it looks better with the line though make sure it reaches to the point where the paragraph of text ends to make it look smooth. Also I would leave a bit more space below the line for a clearer and less crowded feel.