HTML such as this - <div id=”main”><h1 class=”logocolor”>Big Title<h1><p class=”alignleft”>blah blah blah</p></div> - is perfectly valid. The CSS which goes with it is also valid. But what a lot of code!

#main {
	font: 12px/18px Verdana, Geneva, sans-serif;
	padding: 20px;
	border: 1px solid #000;
	}
h1.logocolor {
	color: #C00;
	text-align: center;
	margin: 10px auto;
	font-size: 24px;
	line-height: 36px;
	}
p.alignleft {
	text-align: left;
	margin: 10px 0;
	}

Sometimes there is no way to avoid such detail, but the other day I was working on a client’s site and reduced over 800 lines of CSS code to less than 200, as well as cutting the HTML by almost 20%. A methodical, consistent approach to writing code, making the most out of inheritance can work wonders.

If I set a font, its size and color in a body declaration - body{font:0.8em/1.2em Verdana, Geneva, sans-serif;color:#000;} - those attributes will apply to all the text on the page, except the contents of tables. That is inheritance: just as in the real world, children inherit from parents, in CSS, elements inside others (children) inherit from the elements within which (parents) they appear. The only tricky aspect is learning when parameters are not inherited.

Some instances of no-inheritance are common sense. For example, it is possible but highly unlikely, that if you put a border around a block, you would want borders around every element within that block. So borders are not inherited. Nor are margins and padding, by the same logic. The lack of inheritance in the case of tables (which will revert to the visitor’s default font settings if you are not specific), is less obvious and the subject of debate. For now at least, inheritance in tables is limited to the elements within a table inheriting from their parents (td from tr and both from the table tag itself).

Purists would like to see your CSS look like #header{div div p ul li a span: parameters;}. In other words, you would not apply class names to anything except the holding block, using a section’s relationship within its block to identify it for the purpose of setting its styling. That certainly makes for admirably minimal HTML, but to my mind it is turning a tool into a weapon with which to punish yourself. Certainly it makes no sense to give every li a class of its own, when all those in a block will be treated the same way. In such circumstances, #thisdiv li{parameters} is much more appropriate. Indeed, if your list items are all to look alike, a single li{parameters} is all that is needed to cover them all. But at the other extreme it is hard to justify attempting to visualize a complicated nested structure, particularly as later editing and the addition or removal of a “child” might totally screw up that carefully thought-out CSS. So use ID’s and class names when you must: just try to keep them to a minimum.

Inheritance is also useful because it can give us a head start on dealing with the reality that the default parameters for certain elements are not handled the same way by all browsers.

.oddbox {
	width: 12em;
	float: left;
	padding: 0.5em;
	margin: 0.5em;
	border: solid 1px #000;
	background: #EEE;
	}
.evenbox {
	width: 12em;
	float: left;
	padding: 0.5em;
	margin: 0.5em;
	border: solid 1px #000;
 	background: #CCC;
	}

You recall the way that several message boards present alternating posts with different-colored backgrounds? The CSS above would acheive that. But look at how much of the code is common to both. A close relation to inheritance (this time the pun was deliberate) is multiple classes.

.box {
	width: 12em;
	float: left;
	padding: 0.5em;
	margin: 0.5em;
	border: solid 1px #000;
	}
.odd {
	background: #EEE;
	}
.even {
 	background: #CCC;
	}

That’s better, although the HTML takes a few more characters to become <div class=”box odd”>blah blah</div><div class=”box even”>blah blah</div>. Any number of class identifiers may be combined for a single element, separated by spaces. Or perhaps you prefer grouped classes?

.oddbox, .evenbox {
	width: 12em;
	float: left;
	padding: 0.5em;
	margin: 0.5em;
	border: solid 1px #000;
	}
.oddbox {
	background: #EEE;
	}
.evenbox {
 	background: #CCC;
	}

Grouping classes is when you assign the same parameters to more than one class and this allows the HTML to be written exactly as it would have been originally: <div class=”oddbox”>blah blah</div><div class=”evenbox”>blah blah</div>. Multiple and grouping both promote sparse CSS code, so use whichever you feel most comfortable with.

Okay, we have covered some purely practical stuff, now let’s dig a bit deeper into CSS to understand its mechanisms better. You probably call your stylesheet by @import “mystylesheet.css”. It may not be too relevant to adult webmastering, but you could introduce url into that statement. Doing so allows you to set different stylesheets for different media:

@import url("mydisplay.css") screen;
@import url("myprint.css") print;

And why Cascading style sheets? Contrary to what many think, this is not a reference to the inheritance of properties that we touched on above, nor that more than one sheet may be used for a single HTML page, but to the way that the application of style rules are cascaded. Think about it, if you put a “naked” HTML page online, in other words, no decoration, just structure, a font will still be chosen, along with colors, font-sizes and even some margins and padding.

This is because stylesheets, sometimes partial and sometimes only simulating stylesheet behavior, come from three sources: the author of the document being delivered; the visitor, who can do anything from specifying font faces and sizes through to provide his own style sheet for the sites he/she visits; and the browser being used. Obviously these three sources may make overlapping, often conflicting demands.

When such a conflict exists, this is the (descending) order of priority, the Cascade which is applied:

• User important settings
• Author important settings
• Author normal settings
• User normal settings
• Browser settings

Further, specific selectors (such as <p> will override general ones such as <div> and finally, if two settings score equally, the last one specified is chosen. In this context, styles added to HTML are considered as having been specified after settings in an imported stylesheet.

Important? What does that mean in this context? For example, someone with poor eyesight can set a stylesheet for his/her browser which includes body{font-size: 16px !important;}, which according to the hierarchy shown above, means he/she will see all your normal fonts at this larger size. Authors may also use the !important qualifier, but it’s practical value is limited. However, if you wanted to ensure that a style setting was not accidentally superseded by repeating it later in your CSS, you could make the first entry !important. Unless you also added !important to the second appearance, the first would retain precedence.

Heavy stuff, so let’s finish with some light relief, a few CSS attributes which are not so commonly used.

• {text-transform : capitalize;} - here is some text
• {text-transform : uppercase;} - here is some text
• {font-variant : small-caps;} - here is some text
• {letter-spacing : 4px;} - here is some text
• {word-spacing : 20px;} - here is some text
• {cursor : pointer;} - run your mouse over this to see how it could be useful for submit buttons, etc
• {text-decoration: none; border-bottom: 1px dashed #00F;} - here is some text (a nice change)

A good way to use Inheritance to help overcome common cross-browser incompatibilities, is at the top of every CSS file, try this: body,h1,h2,h3,h4,p,ul,form { margin: 0; padding: 0; } Other elements can be included, but these are the most common.