In this article we will look at what might be considered best practices, or perhaps, good coding habits to get into. To begin, we will look at removing any defaults that a browser may add to our elements and then look at how we can explicitly set the values we want. If you are new to CSS, you may want to bring yourself up to speed by reading a series of tutorials I wrote called An introduction to CSS. This links to the first tutorial in the series, which has links to all the earlier tutorials.
The beauty of CSS is the control it gives us. If used correctly we can perform site wide changes on thousands of pages in seconds. If used incorrectly, CSS is little better than using font tags. The difference between getting it right and getting it wrong is huge, it really is. The object of CSS is to separate design from content. The greater the separation, the easier our life becomes, as we shall see.
We can use CSS in three ways.
Inline CSS is the least flexible of the three options listed above. When applying inline CSS you are styling your elements right inside the code. You can see an example of inline styling in Listing 1 below:
<p style="margin: 20px;">My paragraph text</p>
Listing 1: An inline style
The inline style in Listing 1 above is highlighted. Why is this method a poor one? The answer to that is simple, the style we have applied to that p element is only affecting that p element. This means that every single time we use a p element we will need to write an inline style to force the 20px margin we want to add to our paragraphs.
This situation is further complicated when we need to make changes to our code. Let's say my client wants to reduce the margins on his paragraphs from the 20 pixels we have set to 15 pixels. The site may contain 1000 pages, to complete the client's request we would need to find and change every single instance of that inline style on every page within the site; a job that could take hours.
Embedded CSS is somewhat of a halfway house between inline styles and an external style sheet. An embedded CSS file keeps our styles out of our code and moves them into the head of our document. An example of an embedded style sheet can be seen in Listing 2:
<style type="text/css">
p {
margin: 20px;
}
</style>
Listing 2: An embedded style sheet
An embedded style sheet is contained in an opening and closing style tag pair, and it exists in the head of your page. The problem here is that it exists in the head of every page. If we revisit our client's required change of reducing the margin on our p element from 20 pixels to 15 pixels, we do have a slight improvement. We would now only need to change the setting once in each page, from within our embedded style sheet. This is much better than changing many inline style instances in every page. Better, but still not great.
An external CSS file is the way to go. An external CSS file is exactly what it says; it resides outside the (x)html document. From there it is linked to from within the <head> of the document, and the link implements those external styles onto the page. Each page in our web site might carry the same link to the same style sheet, allowing each element within our pages to adopt its styles from a single CSS file. This is a major advantage to us, because it means that we only need to change any given selector in a single location - our external style sheet - and the changes we make to that selector will propagate throughout all our pages, so long as those pages are linked to the external style sheet.
An example of a link to an external style sheet can be seen in Listing 3:
<link href="/external.css" rel="stylesheet" type="text/css" />
Listing 3: Linking to an external style sheet
The selectors within our external style sheet would be written in exactly the same way as they would be in our embedded style sheet, the only difference being that we don't need to include the surrounding style tags in our external CSS file, as you can see from Listing 4:
p {
margin: 20px;
}
Listing 4: A selector from our external style sheet
An external style sheet is without a doubt the way to go, and your aim should always be to keep your selectors within your external style sheet. That is not to say that inline or embedded style sheets do not have their uses, they do, but those instances are the exception rather than the norm.
You can get further information on creating and linking an external style sheet to your documents in Dreamweaver by reading a tutorial I wrote earlier called: Creating An External Style Sheet In Dreamweaver MX
We'll begin by removing the default margins, padding and borders that a browser might add to our elements as it sees fit. A nice way to "zero off" all the defaults is to do so by using a single selector, placed at the very top of your style sheet.
Why the top of the style sheet? As we learned in CSS An Introduction - Part Four: Type Selectors and Grouping, we can override any previous values from lower down in the style sheet. The word we are looking for here is specificity. If two selectors are of the same weight, or importance, then the one closer to the element that is being styled wins. Looking at the two selectors below, the first selector incorporates many elements and is used to do nothing more than zero off all the typical browser defaults on those elements.
html, body, ul, ol, li, p,
h1, h2, h3, h4, h5, h6,
form, fieldset, a {
margin: 0;
padding: 0;
border: 0;
}
Listing 5: Zeroing off the defaults
Each of the elements in the selector above will have all their margin, padding and border values zeroed - if they exist - when the browser begins to render your page. This means that all the defaults are removed, and you are left with a level playing field to build the page in the manner you want the page to display. Take a look at Listing 6 below:
p {
margin: 20px;
}
Listing 6: Specifically set margins to suit each element
The p selector shown in Listing 2 will re-introduce a margin setting to our p element, giving a margin of 20 pixels to all four sides of the element. What we have done here is provide a setting that will consistently display the p element the same way in all browsers. This kind of rule overriding can of course be repeated for each of the elements listed in our "zeroing" rule.
In Image 1 below, we can see a fieldset being rendered by Internet Explorer and Firefox, and it is the same fieldset in each case. The difference between the two is vast, and if you accepted such default rendering you would never get a good consistent cross browser rendering of your page, as you can see.
Image 1: The difference in default settings
In Image 2 we can see the effect that our zeroed settings have had on the fieldset. We now have a level playing field, starting from a point where the display of our elements is equal. You will notice that the legend is shown in blue by default in Internet Explorer and black in Firefox; this is of no consequence. The text color and settings we would usually set explicitly within the fieldset selector, but if you preferred, you could even add a color and background color to our default zeroing selector, and then override those settings just as we did with the paragraph margin.
Image 2: Our default selector gives us a level starting point
This is a very important part of designing with CSS. Check your pages constantly, the more you check while coding, the less debugging you will have to do at the end. Although Dreamweaver MX 2004 does a pretty good job of rendering CSS layouts, it is not perfect. There is only one trustworthy place to check your pages, and that is in the browsers you wish to support.
The first thing you must have in your pages is a valid doctype.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
Listing 7: A valid xhtml transitional doc type
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Listing 8: A valid html 4.01 loose doc type
Holly Bergevin has a good article on doctypes that you would do well to read up on if you are unsure of what is, and is not, a valid doctype. A valid doc type is critical to your work, so always ensure your doctype really is correct and valid. A single incorrect character in a doctype can invalidate it.
It is worth remembering that even if you do have a valid doctype, placing anything above it in the source code - even a comment - will cause Internet Explorer 6 to drop into quirks mode. If IE6 is in quirks mode, you will see that your CSS is rendered similarly to IE5.5, meaning in the same "quirky" fashion as that old browser. This doctype bug happens only in Internet Explorer 6.
The browser you use to check your pages while creating the layout is important. If you are using a browser as a test bed for your layout, then it must have the capabilities to render your pages correctly. That may sound obvious, but no browser is perfect and I have seen many designers get into trouble with their layouts through poor testing.
Personally I use Firefox for my testing, as any of the Gecko browsers do a good job of rendering your CSS, as does Opera 7 and one or two others. Designers tend to run into trouble, specifically the less experienced ones, by testing in Internet Explorer first. This browser is flawed, it has some really nasty bugs, many of which have been documented by John Gallant and Holly Bergevin on the CommunityMX site. You should test your pages in a good browser first, and only then provide fixes for the more challenged browsers.
You can give your ID and class selectors any names you like, but, providing meaningful names does make a difference. They should be names that you will understand when you return to the CSS file some time down the line and you need to make adjustments. Take a look at the two selectors below in Listings 9 & 10:
#wrapper {
margin: 0 auto;
}
Listing 9: Providing a good name for a div that contains all other elements
#div1 {
margin: 0 auto;
}
Listing 10: A selector that means absolutely nothing!
It is important that our selector names are easy to understand in relation to what they are controlling within our document. Something you will tend to see from time to time is poor use of the class selector, take a look at Listing 11.
.lightblue {
color: #52A5F2;
}
Listing 11: A class selector called lightblue
Once again this tells us nothing about how the class might be applied.
You will, at times, come across pages where such a class name is applied to all instances of the p element on that page. It would be far better to write the above as a type selector, as shown in Listing 12:
p {
color: #52A5F2;
}
Listing 12: Choose your selectors wisely
In Listing 12, it is immediately obvious what the light blue colour is being applied to. This makes the CSS file easier to maintain, saving you both time and money on a commercial job. These are not complicated things, they just require a little thought when you build your CSS file. The effort spent is repaid many times when maintenance time comes around.
While we are on the subject of text, I'll mention relative font sizing. Internet Explorer does not enable resizing of pixel sized fonts by default, and this creates problems for us from an accessibility standpoint; It means many of our users will not be able to resize the text if they need to. A relative font sizing in em or % is resizable in IE, and will serve you far better.
When working on your design you should test text resizing to see how your page reacts. A well designed page will flow with the resize, while a poorly designed page will allow elements to overlap and the page becomes unreadable.
This is a common problem with Dreamweaver users who are new to CSS design. It is all too tempting to pick up the draw layer tool and start drawing divs where you want them. Unfortunately the draw layer tool produces absolute divs - referred to as "layers" in Dreamweaver. This is not the way to go about laying out a page with CSS.
When we declare a specific font to be used within our design, we are doing so in the hope that the user will have that font installed on their system. If they don't have the font on their system, then they won't see it, simple as that. What we need to do is reference fonts that the user will likely have on their machine, such as the ones in the font-family property below. It is important that we finish the list with a generic font type.
In Listing 13 I have finished with a reference to sans-serif. This means that even if the user has none of the fonts I specified on their machine, they will at least see my content in the general type of font I want them to see it in. This prevents a serif font like Times New Roman from being used, which would give my page a completely different look than the one I intended.
font-family: Arial, Verdana, Helvetica, sans-serif;
Listing 13: Choosing the font and font type
When you are dealing with a font whose name incorporates more than one word then it is necessary to surround the fonts name in quotes e.g. "Times New Roman".
Comments are a fantastic way of giving your memory a jog. It is a good idea to comment any code you have written that might be a little bit out of the ordinary, or something you did to work around a problem. Comments really can save your life (or your job) later on down the road. You can place comments in your CSS file by using the following syntax:
/* I reduced the font size in the footer */
#footer P {
font-size: 70%;
}
Listing 14: Leaving comments to refresh your memory
It also a good idea to order your CSS file. You might consider setting up your CSS file to read something like that shown in Listing 15:
/* Start laying out the navigation area */
Your navigation styles
/* Ends the navigation area */
Listing 15: Breaking down your CSS file into sections by using comments
Earlier in this article we looked at getting rid of the browsers' default settings, we did this by zeroing off the margins, padding and borders with a single selector. In this section we are going to talk about doing the complete opposite — setting a group of custom default values that will be applied throughout our web site. A good place to set these defaults is on the body tag. Take a look at Listing 16:
body {
font-size: 100.01%;
font-family: Arial, Verdana, Helvetica, sans-serif;
color: #ccc;
background-color: #fff;
}
Listing 16: Setting up some default values
This odd 100.01% value for the font size compensates for several browser bugs. First, setting a default body font size in percent (instead of em) eliminates an IE/Win problem with growing or shrinking fonts out of proportion if they are later set in ems in other elements. Additionally, some versions of Opera will draw a default font-size of 100% too small compared to other browsers. Safari, on the other hand, has a problem with a font-size of 101%. The current "best" suggestion is to use the 100.01% value for this property.
In Listing 16 we have added a default font-size of 100.01%. Once we have set this base size it is easy to make adjustments by scaling off it for each of our individual elements. We might declare a p element to have a font size of 80%, this would be 80% of the value declared on the body element. Similarly we may declare a font size of 135% for an h1 element, this would again scale off the default setting on the body.
Some designs dynamically reset the entire page text size by controlling font-size on the body, but we can't do that if it must remain set to 100.01%. As an alternative, you may enclose all the elements in a wrapper div, and dynamically set a font-size value in ems on that wrapper, which achieves the same thing as controlling the body font-size.
Next we have the font-family. Once we have declared a font-family value on the body, we have no need to declare it again unless we want to change the font-family for perhaps an h1 element that we might want to have display in a different font such as "Georgia". The same can be said for our color and background-color values. All text in our document will be black and the page will have a plain white background, unless we specifically override the body settings in following rules.
By creating a set of defaults like this, it prevents us having to declare such values over and over again throughout our style sheet. We would now only need to declare values when we want to change something away from the default settings.
In this article we have explored methods of deploying CSS that will make our lives a little easier. I would hesitate to call them best practices, as everyone's version of "best practice" will vary, but I would say they are good coding habits to get into.
I hope you found this article a worthwhile read, if you have any comments I'll see you in the forums.
Until next time :~)
Approximate download size: 104k
Keywords
CSS, style, sheets, good, coding, habits, best, practices, comments, selectors, flow,
