Hey Folks,
The navigation bar of my website has a background image and is common to all it’s pages. The thing is that each page covers a different amount of vertical space.
Is there any way to make the length of the background image adjust to each page other than with an inline length attribute?
Thanks in advance for the feedback.
jcmcobra
Please post a link to your site.
You could have a different background image on those pages, but are you saying that the navigation is a different size on each page? That is hard to picture. As Victorinox says, we need to see the site to understand what’s going on.
O, I see: presumably you mean the image down the left side? Given this layout (sidebar stuck to left side), the easy solution is to put the background image on the body element and set it to repeat-y.
Yes, the repeating red drum. I’m using repeat-y now and specifying length: 100%. Previously I had repeat-y along with a specific length in pixels. The problem is that a couple of my pages need to be scrolled considerably, and the image will not repeat beyond the specified length. If I omit a specific length the image will not repeat at all.
You didn’t hear what I said about placing the image on the <body> element, though.
height: 100% doesn’t work like that. It can only work if the container element has a set height, too, but that wouldn’t work here. As I said, bplace the background image on the <body> element and it will do what you want.
ooooooohh! I thought maybe you meant to put it in the body of my page. Let me try that.
Thnx again,
jcmcobra
Actually, height: 100% is working exactly as it’s supposed to (fits the height of the screen), but I need it to adjust beyond that when necessary. Please be patient with my ignorance, I don’t understand what your mean by “bplace the background image on the <body> element.”
I mean move the background image to here:
body {
background-color: #E2EDFF;
border: 0pt none;
font-family: Verdana,Helvetica,Arial,sans-sarif;
line-height: 125%;
padding: 0pt;
[COLOR="#FF0000"]background: url("Images/Images/djembe-drum.jpg") repeat-y scroll 0% 0% #7DA5D8;[/COLOR]
}
The result won’t be quite what you want at first, as the image itself is wider than the sidebar, so I’d suggest trimming that image a bit to the actual size you want (i.e. a width of 180px). 
Wait. That’s going to apply to entire body.
The repeat-y means it will only repeat down the left side. If you want to hide it at certain points, that can be done easily, like putting a background color on the header div. You probably also want to add margin: 0 to the <body> element to remove the gap all around the outside of the screen, too.
body {margin: 0;}
That is one of the most broken messes of a page I’ve ever seen… just what are you trying to make this look like? (checks it in FF, suspect my large fonts setting screwing with it)… no, it’s kinda broken and useless there too…
Do you have a pic of what you’re trying to make it look like? I don’t think it’s working here at all…
I do suspect a lot of your issues stem from all the pointless extra wrapping DIV you have around the H1, UL, etc, etc… for what I’m seeing for appearance you’ve got easily 50% more markup than neccessary, and on some things (like the inlined style and inlined bullet characters) missed the point of semantic markup and using CSS.
The overstuffed keywords and nonsensical description metas, HTML 3.2 in a XHTML STRICT doctype, nonsensical heading orders, and oddball formatting/comment placement certainly can’t be helping any either.
Thank you ralph.m. Your suggestions worked fine. I was making the mistake of repeating the background image within my navigation element.
Many thanks,
jcmcobra
This is my first effort at web design. The original version had only 4 pages and was much simpler. Virtually all the formatting was done via SS.
Little, by little I’ve added elements and pages. Much of this was done inline, since I had no intention of repeating it elsewhere on the site. As you say, it’s become a mess.
By the way, what exactly was your suggestion?
Thank you again,
jcmcobra
Here’s one easy to implement suggestion to get the clean-up underway: remove the line breaks from your paragraphs and let the text flow and wrap naturally. (The breaks are also malformed and should be <br /> rather than </br> which causes some browsers to ignore them.)
For example, the following code:
<p><span class = "fun"> The Drum Dr. </span> is a band of dedicated
music enthusiasts with a very special emphasis on hand drums.
We are based </br>in Santa Cruz, CA, which means that we tend to be
open minded and easy going, but please do not misunderstand. </br>
We do not lack passion. We love drums: African drums, Middle
Eastern Drums, Native American drums, Asian </br>drums, South American
drums.
</p>
in a browser window of around 800px, produces less than desirable wrapping:
With line breaks removed…
That seems useful. I’ll try it, Thank you.
SS?
For just starting out you aren’t doing too bad – you’re just being led down a path that many of us also encountered when just starting out; an over-reliance on tools, bad/outdated methodologies from web-rot and shelf-rot sources, etc, etc…
Longer a site lives, the greater the chance of that happening… though really the base site template shouldn’t have those sorts of issues, only the content area.
I would suggest throwing it all away and starting over… there’s little to salvage from the original markup as it fails to follow a number of modern conventions. First order of business would be some new markup… something like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml"
lang="en"
xml:lang="en"
><head>
<meta
http-equiv="Content-Type"
content="text/html; charset=utf-8"
/>
<meta
name="description"
content="Why buy a new drum when we can make your beloved old friend better than new? Our professionals hand repair most all types of drums."
/>
<meta
name="keywords"
content="drum,djembe,jembe,ashiko,kora,balafon,repair,san francisco,santa cruz,monterey,bay"
/>
<link
type="text/css"
rel="stylesheet"
href="screen.css"
media="screen,projection,tv"
/>
<title>
Hand Drum Repair
</title>
</head><body>
<h1>
<span>The Drum Doctor <span>-</span></span>
<small>Hand drum repair, maintenance and reconditioning</small>
</h1>
<div id="columnWrapper">
<div id="sideBar">
<ul id="mainMenu">
<li><a href="index.html">Home</a></li>
<li><a href="about-drum-repair.html">About Drum Dr.</a></li>
<li><a href="drum-repair-histories.html">Drum Repair Histories</a></li>
<li><a href="drumming-events.html">Drumming Events</a></li>
<li><a href="djembe-repair.html">Djembe Repair</a></li>
<li><a href="djembe-history.html">Djembe History</a></li>
<li><a href="tabla-repair.html">Tabla Repair</a></li>
<li><a href="drum-doctor-contact.html">Drum Dr. Contacts</a></li>
<li><a href="repair-rates.html">Repair Rates</a></li>
</ul>
<!-- #sideBar --></div>
<hr />
<div id="content">
<h2 class="lifeHeading">
Santa Cruz Hand Drum Infirmary
</h2>
<img
src="images/djembe.jpg"
class="trailingPlate"
width="250"
alt="Rope-tuned, djembe hand drum."
/>
<h3>Don't throw your money away!</h3>
<p>
Did your dog confuse your djembe with his chew toy? Maybe you left it in the hot car too long and the goat skin popped, or it fell out of the back of your pickup on your way to the drum circle. Do not wast your money on a new drum!<br />
<a href="drum-doctor-contact.html">Contact Us Now!</a> ...and save your money.
</p><p>
We specialize in drum head replacement and tuning of:
</p>
<ul>
<li>Djembes</li>
<li>Frame Drums</li>
<li>Ashikos</li>
<li>Doumbeks</li>
<li>Congas</li>
<li>Bongos</li>
<li>Tablas</li>
<li>Dholaks</li>
<li>Djun Djuns</li>
<li>Bougarabous</li>
</ul>
<p>
Whether your drum needs tuning or a complete overhaul, you've come to the right place. We replace broken skins, repair cracked drum shells, resurface bearing edges and replace tuning rope -- all with the care and attention we would give to our own instrument. We repair hand drums.
</p><p>
Jim Greiner, internationally renowned, award-winning percussionist, clinician and educator has this to say about The Drum Doctor:
</p>
<blockquote>
<p>
I highly recommend Dr. Tom for his exceptional work on hand drums. I've recommended him to students, drum circle participants and to fellow professional percussionists many times over the years, and he has always delivered top-notch work, always within the time frame he suggested, and always with a professional and upbeat attitude.
</p><p>
Thanks Doc for providing such a great service to the drumming community!
</p><p>
<cite>
Jim Greiner
<a href="http://www.handsondrum.com">www.handsondrum.com</a>
</cite>
</p>
</blockquote>
<p>
So why buy a new drum, when our loving care will make your beloved old friend better than new? For a no obligation, free consultation <a href="drum-doctor-contact.html">Contact Us Now!</a>
</p><p>
We're located in Santa Cruz, CA, easiliy accesible to anyone in the San Francisco Bay Area, San Jose/Silicon Valley and the Monterey Bay, but don't worry if you're not in our neck of the woods; we have years of shipping experience. Many of our customers ship their ailing drums to us, and we ship their restored drums back.
</p><p>
Qualified to treat other drums and ethnic instruments such as koras and balafons--just ask!
</p>
<hr />
<div id="onDuty">
<span>On Duty:</span>
Dr. Tom (The Drum Doctor)
</div>
<!-- #content --></div>
<!-- #columnWrapper --></div>
<hr />
<div id="footer">
© 2011 - <a href="/">The Drum Doctor</a>
<!-- #footer --></div>
</body></html>
To break that down for you – first off I gut out the pointless analytics nonsense; it’s basically wasting bandwidth and time on information that you should already have meaningful versions of on the server, which can be gleaned from the logs using tools like AWStats, Analog and Webalizer. If you need more information than those, you’re likely wasting time fretting over inconsequential statistics instead of taking the time to build what’s important for any website, FRESH CONTENT.
I include the full language encodings like a good little doobie. The new HTML5tards will try to tell you to gut that down; I say it’s only a few bytes why risk some user agent screwing it up. You’ll notice I’m VERY strict in the formatting of my code – a little tab here and a carriage return there, and the time spent lining everything up nice and pretty saves a lot more time later when it comes to debugging. Also notice my comment placements – there’s no reason to waste time saying “end” since </div> means end of something… and I put the comment before the close. If comments end up between sibling floats, or between sibling block and inline tags, they can actually trip rendering errors in most every version of IE and certain versions of Firefox. Yes, that’s right, COMMENTS can trip rendering bugs. Simply moving the comment about what’s being closed before the closing tag prevents this error. It’s a practice I really think everyone should get in the habit of.
I also like to keep like tags in HEAD together… and as a rule of thumb the first thing you should have in your HEAD is the character encoding, so that means META’s first.
Notice I edited down the description to two plaintext sentences – since the description meta exists for the sole purpose of appearing below the link on your SERP result, it should be inviting natural language text, preferably something under 192 characters. (this is like 130ish… 128 is the ideal, so close enough).
The keywords is also called “KEYWORDS”, not keyphrases, not keysentences, keyWORDS – the ONLY time I’d allow more than one word between commas is in proper names – like the cities. Otherwise think of it as a word jumble… “drum, djembe, jembe, repair” is functionally identical to “drum repair”,“djembe repair”, “jembe repair” – and even “djembe drum repair”, “jembe drum repair”, “repair drum”, “repair djembe” or any other combination of words. ALSO, any words you put into keywords should appear in your BODY area, otherwise they are ignored. This is where the MYTH that search engines ignore the keywords meta actually comes from… as if you put words in there which are not in your document text, yes, it is ignored… you use words that are in the text, those words get a slight boost in weight. Ideally it should be 8 to 10 words comma separated. (which is why I laugh when I see people put things like horizontal breaks or hyphens in as delimiters, welcome to your run-on sentence)
The CSS link includes the media types “screen, projection, tv” – basically the devices for which your screen target CSS is meant for… This way style that is total gibberish for print or handheld don’t get sent to those devices… naturally you may want to add separate stylesheets for those, and with media queries making a single column version of the layout for really small screens might not be a bad idea either.
I always put <html><head>, </head><body> and </body></html> on single lines to remind myself that NOTHING should EVER be placed between those tags. It’s amazing how often people forget that.
Notice no header div – don’t need it… no sitebranding div… don’t need it… No classes or ID’s… don’t need 'em. The H1 is the heading under which all other content on the page is a subsection – this is why you should only ever have one h1… and if there’s only ever one, it’s really easy to target from the CSS. It’s also a perfectly good block-level container, meaning all that style is easily applied to it.
The H6 is dropped to put it inside the H1 inside a SMALL tag. This is common practice for taglines… The H6 made no sense at all, since that’s basically saying “I’m starting a subsection of a H5” – leading to the question, WHAT H5?!? It is improper practice to skip heading levels; I suspect you fell into the trap many of us did starting out of thinking that the default appearance of the tag has ANYTHING to do with it’s meaning – as I quite often say if you choose a tag based on it’s default appearance, you’re choosing the wrong tags!
DIV#columnWrapper – Standard container I use when there’s going to be columns – This is where I’d be putting that repeating sidebar image of yours, on this element which wraps the sidebar and content, so it adjusts to the height.
DIV#sideBar – standard sidebar wrapping div… If all you EVER plan on having in the sidebar is the menu, I’d consider dropping this DIV altogether, however I put this in as usually I would have more in the sidebar than just the menu.
UL#mainMenu – the menu… Gave it an ID just in case you add other UL to the sideBar, or decide to move it out of the sidebar.
DIV#content – simple main content area wrapper.
H2.lifeHeading - I added the class to apply that image as to me I didn’t really feel like that was a content image. Looks bad when CSS is disabled, so let’s apply that with background in the CSS instead.
img.trailingPlate – and image is NOT a paragraph, anyone telling you otherwise is packing your fudge. No reason for an extra DIV around it, no reason for the P, it can be styled JUST FINE directly with a single common class. I usually run three classes for plate images (borrowing from the typography term)… .leadingPlate (float:left), .trailingPlate (float:right) and just plain .plate… using floats means if you let the paragraphs after it just flow, you don’t have to have those manual line-breaks in there (which is part of why it was breaking here – see Victorinox’ post)
Next is another heading… You were using an H4… where’s the H3? Again, don’t skip numbers… Using a H3 means it’s the start of a subection of the H2 before it. If it is NOT actually a subsection of that heading, a H2 (sibling) would be the more appropriate choice…
As you can see, no BR in the paragraph that follows it – let flow do it’s job, don’t try to micromanage that stuff as it WILL break.
I recombined the UL down to a single entity – manually adding the bullets is a bad idea, as is the manual split into multiple lines… again, let flow do it’s job and do all that styling on the CSS side.
More para’s, blah blah blah…
Then there’s your quote… it’s a quote, we have tags for that… it’s not a inline quote as it’s multiple paragraphs, so that’s a candidate for BLOCKQUOTE… since you also have the source being quoted in there, that’s your CITE.
More paragraphs…
div#onDuty – this really didn’t look like a content paragraph and/or part of the previous heading, so I use a horizontal rule to indicate the change in topic, and put it in a div as it’s really not grammatically paragraph.
Close out Content, close out #columnWrapper, we have the footer. The footer also didn’t really strike me grammatically as a paragraph, so I left out any excess block level containers on it.
Close out everything and that’s it. I usually write up the entire HTML for a page template before I even THINK about applying layout to it. A few standard containers, horizontal rules to indicate topic changes – This way I know that should CSS, Javascript or any of the other enhancements to a page be missing/unavailable/blocked, the end user still gets a reasonably attractive and functional website; the ENTIRE POINT of HTML in the first place… I then progressively enhance the page by using CSS to bend that HTML to my will, making as few changes as possible – since progressive enhancement during construction is the easiest way to have graceful degradation once deployed.
If I have time later I’ll put together some demo CSS with a similar breakdown of the how/what/why to illustrate my approach further.
Here’s what I came up with:
http://www.cutcodedown.com/for_others/jcmCobra/template.html
as with all my examples, the directory:
http://www.cutcodedown.com/for_others/jcmCobra/
is open for easy access to the bits and pieces. Valid XHTML 1.0 Strict, would be valid CSS3 if not for a couple of browser specific properties and it being a bit #DDD about how “0” is handled on the new CSS 3 properties.
As you can see I took a few stylistic liberites – wasn’t wild about that repeating image at the top as the text just didn’t fit next to it, looked bad over it, and the dynamic (%/EM) fonts just really broke it on my system (large fonts/120dpi vs. the default 96dpi – which is oddly the reason to USE %/EM, but use it wrong and it’s just as bad). Likewise I resized/remastered all the images so to consume less bandwidth, which combined with the code changes takes the page from a massive 241k, down to a mere 54k…
Gimme a bit, I’ll write up a breakdown of the CSS which will hopefully explain it to you.
Ok, on to the CSS… Break it down…
First I have my reset – browsers do not start with the same default paddings/margins/borders on elements, so it’s usually handy/easier to just set the offending elements up front. There are larger resets, but those tread into the area of being frameworks instead of resets – massive ones like Eric Meyer’s “Reset Reloaded” being one of the worst offenders on that, or as I like to call it “You give resets… a bad name”.
Likewise there are smaller resets, like the ‘universal selector’ reset of * {margin:0; padding:0} – which pretty much shtups styling form elements beyond repair.
My reset is in the middle, the nice safe middle ground. Reset JUST the margins and padding on the offending cross-browser elements, strip the border off the TWO offending elements there… and done. Being only 250 bytes, I really don’t sweat it, it’s certainly less code than saying “padding:0; margin:0” every time I use one of those elements.
HR – I hide all HR on the page as I tend to use borders for that on other elements for “screen”. To me, HR are to – as the HTML 3 description used to say – “indicate a change in topic”. They make the document make sense for user agents where CSS means nothing… when we have our nice screen appearance, we don’t need 'em, so get rid of 'em.
.plate,
.leadingPlate,
.trailingPlate – my standard content containers for plate images. The first one gets set to block and centered, the next two are floated with enough margin to look nice. I then set a border and box-shadow on all three for consistency sake. The box-shadow doesn’t show on older browsers (IE8-) – it’s a minor visual effect that frankly, is not essential to the page working, so OH WELL. IE8 and lower don’t get the shadow, whatever will we do. Naturally, someone will pipe in suggesting using some fat bloated javascript shiv as a fix; they’re what I like to call… well, I’ll be nice, I won’t say it.
body – set the default font, set the background… and here’s the big trick, I put your tiled sidebar background HERE. Since you seemed to be designing for full screen instead of the typical “box in the middle” this means no extra elements were needed for this. I give it a bit of a push down from the top to make it line up with the end of the header area a bit more.
h1 – I set the font size to 100% so we can scale “small” properly… and set up the tiled background. If you want to go back to the tiled version you had, it would go here. Since it’s the first element, I recreated that top border you had here.
h1 span – The large text next to the image ends up needing the extra span container just to make all the padding’s play nice. I set this to a px font due to the image interaction – letting it resize automatically can result in a broken layout… and besides, NOBODY is going to kvetch about 44px being “too small”. I put the logo image here just once because to my sensibilities, it just looked better. To switch back to what you had, just drop that background and play with the paddings on this element. The display:block is there just to let us set paddings. I also did a text-transform to uppercase since I liked that better – long term I’d consider maybe using some form of web-font or image-replacement here for better branding.
h1 span span – The hyphen I put in there for non screen.css users we just take right out of the equation with display:none; – being just a single hyphen, nobody’s gonna mistake that for content cloaking. Also helps that some screen readers will now ignore the hyphen.
h1 small – like the span, this gets display:block so we can play with paddings properly. I left this as dynamic font and boosted it a bit. Borders, colors, your background image, nothing too fancy needed here.
#columnWrapper – this element serves two purposes in this layout. The first is to contain our floats so the footer will behave. The second is to apply a minimum and maximum width so that when the page is too small the layout doesn’t break, and when it’s too big you don’t have sentences that are too long to read.
The overflow:hidden is a natural trigger for float wrapping behavior, probably the simplest there is. Unfortunately old versions of IE don’t obey it, but there’s a oft used ‘trigger property’ hidden in IE called “haslayout”. Triggering ‘haslayout’ on an element can often fix rendering oddities in legacy IE on that element OR it’s children. For more about haslayout I suggest you google it, there are endless articles on the subject. For now, let’s just say that for some reason tripping haslayout makes an element wrap floats inside it instead of collapsing/pretending they aren’t there. Notice I use the IE proprietary ‘zoom’ property. Technically it’s invalid CSS and people used to jump through all sorts of hoops to try and make valid CSS with haslayout triggers. Given the plethora of proprietary values people are slapping on pages these days with all the -webkit and -moz properties, it’s really hard to justify not simply saying “FINE, I’ll just use zoom”… so zoom it is.
I declared the min-width in PX because I’m aiming for 800px wide physical devices… I always take 48px off for things like borders and scrollbar, hence the 752px. Technically you could get away with 40px and cover 99% of what’s out there… or you could go down to 32px which many people use – but is that extra 8-16px really gonna kill us? I think not.
The max-width I declared in EM’s since I’m doign that to prevent lines of text from being too long… since EM’s get bigger based on the user’s preferences, saying PX there would mean large font (120dpi) users (like myself) would get less characters per line than a small font (96dpi) user.
It’s kind-of unusual to set these values so deep into the page as usually there’s an outer-wrapper to handle this… but with the fullscreen layout this made more sense.
* html #columnwrapper – the comment says it all:
/* IE6/lower know not the min/max-width, so give them a crappy litle stripe */
We could fake it with an expression there, but it’s really just not worth the effort. The page WORKS for IE6 users, leave it at that. You waste too much time making it behave in decade old browsers the same as it does in new ones, you just end up with a fat bloated train wreck of a page. Graceful degradation, as fancy stuff becomes available make it available for people with the new stuff, and let the people with the old stuff still get a usable page.
#sideBar – simple floated column layout. I set the width wider than you had because the text was wrapping at larger sizes and was hard to fit… It also helps to use multiples of 2, 4, 8 or 16 as computers deal with exponents of two, particularly those, better than other values. 192 = 16*12
#mainMenu – I took a lot of stylistic liberties here because the text was illegible over that background. First I just kill the bullets and give it some padding. I also set the font as px here. Verdana is a ‘large font’, tends to be bigger than other fonts at the same font-size… because of the narrow px width column using %/em is just asking for a broken layout for large font users, so much like on the H1 px is our answer. Really even 144dpi users won’t complain about 14px verdana being too small – so it’s an acceptable sacrifice.
Doesn’t mean I like it… Does mean I’ll do it.
#mainMenu li – thanks to IE7, LI suck. BAD. Life gave me lemons I’m going to burn down life’s house with lemons BAD. Anchors inside LI in IE7 can do all sorts of funky height-shifting nonsese if you try to style them, so unless I HAVE to use them (like in a cascading menu) I set them to display:inline, which seems to strip away all that nastyness – and then pretend that they aren’t even in the markup.
#mainMenu a – again, display:block lets us play with paddings properly, padding and margin are nothing special. Text-decoration to strip the underlines, and I gave them some color, a border and some cutesy CSS3 effects.
#mainMenu a:active,
#mainMenu a:focus,
#mainMenu a:hover – hover effect… nothing too fancy there.
Content – another behavior overflow:hidden trips is that on block level elements after a float, if the content is taller than the float it won’t indent back in… very desirable in a column based layout… Using this means we don’t even need to state widths here… also very desirable for our semi-fluid layout. Again, legacy IE doesn’t do this, but haslayout trips the same behavior. From there just a wee bit of padding to make things pretty.
Content p – paragraphs by default use margin-bottom (though not in ALL UA’s) – I prefer padding so I don’t have to deal with margin collapse issues. Since we’ve already got a nice padding on our parent container, all we need here is to pad the bottom. pad the top of the container and the bottom of the paragraph, it’s a million times simpler than figuring out how overlapping margins are gonna add up.
Content ul – your inline list. Since you want them inline the auto-bullets aren’t gonna fly, so turn bullets off much like you were, but instead of putting them in the markup, I choose to use a background image for this. Bullets aren’t consistent in appearance cross-browser anyways, and this also lets you change it to any shape you want. (always nice). I give it the same bottom padding as paragraphs so everything spaces out the same, and I pump the line-height to 200% so they space out like you had the two separate lists doing.
Content li – I float these into a lines instead of inline-block so I don’t have to play with any extra properties… simplest solution is usually best. I used a 6px wide image, but only add 4px extra padding difference on the left side because for some reason there’s always an extra 2px in the kerning after the last character… dunno why, but all font engines seem to do this. Apart from that, it’s pretty simple.
Content h2 – I assumed most H2 would be styled the same as your home page one, just without the image or maybe with different images… so get the ‘common’ stuff like size, color and bottom margin out of the way.
Content h2.lifeHeading – the unique one with the image. Again I remastered the image; here’s a BIG tip, NEVER use an image larger than you’re going to show it and certainly NEVER let browsers handle the resize – they suck Cave Johnsons lemons at it. I add 44px total top/bottom padding meaning so long as the font ends up more than 16px tall (which our 150% pretty much guarantees) the image won’t get chopped off top and bottom.
Content h3 – padding, size, color… nothing to write home about.
Content a,
#footer a – Just the styling common to both areas. I dislike setting a globally at the top because :visited can make a royal pain out of itself on things like menus. Notice I set the visited state and even tacked on some nice hover states. I always trap :active and :focus so keyboard users aren’t left out in the cold. Technically all browsers should be using :focus for that, but some legacy browsers use :active instead… This can result in the ‘hover’ state being stuck in some browsers when you navigate back to the page from the link – but it’s a small price for usability.
blockquote – the quote… I did NOT make the text smaller as even at large fonts what you were doing caused massive usability issues. Instead I put quote marks in the markup and just indented it, retaining the different color. I would consider maybe giving it a different background-color, but not sure how that would look.
#onDuty – same bottom padding as para/ul…
#onDuty span – just bold and color, again, simple.
#footer – I clear floats just in case some browser decides overflow and haslayout aren’t enough, use margin to push it in on the left past the sidebar background image, and on the right just to make it even, pad the top and bottom to be pretty, and give it the dividing border. Simple.
… and that’s it… how I’d code that same page. I hope this helps you and that you’ll be able to glean some useful information from it.
Ooph, took me longer to write the description of the CSS than it did to write the CSS.