Best Practices Web Design

Looking for the lessons? Get started!

Some of the more common HTML and CSS errors, with solutions.

The entire Web Design Principles section can be accessed through the menu below.

Unfortunately, not everyone's browser will support the spiffy JavaScript menu behind that innocent-looking button. If your browser won't display the menu, just click on the button and you'll be taken to a separate page with the entire menu displayed in clear, non-JavaScript HTML.

Confidence comes not from always being right but from not fearing to be wrong. — Peter T. McIntyre

No matter how hard we try or how much we learn, we make mistakes. That's a given.

Often, we make the same mistakes over and over again. This section is designed to help you recognize some of the most common mistakes Web designers make, and how to quickly fix them.

This page is cribbed primarily from an excellent article by Web developer Rob Glazebrook, and augmented by material from articles by Christopher Hester, Dynamic Site Solutions, Soh Tanaka,

CSS Mistakes

Missing a semicolon

Every CSS declaration ends with a semicolon: ; .

More about CSS Selectors, Attributes, and Values.

The principles of CSS say that the last declaration in a rule does not require a semicolon, because the closing brace ends the declaration. Some designers, therefore, routinely omit the last semicolon. Like so:

body {
   background-color: #444;
   color: #eee <— Valid, but asking for trouble.
}

There's nothing wrong with this. However, sometime in the future (like say, tomorrow), you may want to add another declaration to that rule. If you forget to add the semicolon, you might get something like this:

body {
   background-color: #444;
   color: #eee <— Oops!
   font-family: Helvetica, Arial, sans-serif 
}

The font-family rule never gets applied, because your browser reads "font-family" as part of the color value.

Solution: Add the final semicolon in all cases.

Missing a colon

This is one of the easiest errors to make. The caffeine kicks in, your fingers start dancing over the keyboard, you start thinking about what you're going to write instead of ensuring that what you're writing this very second. And … whoops!

You should never fast-forward into the future. Because every time you do, you rob yourself of the journey, the present moment, which, in the end, is all there really is. — Alyson Noel

Leaving out the colon (this thing: : ) happens all too often, because it's hard to see it in the midst of all the strange code:

body { 
   font-family Helvetica, Arial, sans-serif; <— Oops!
}

You'll see this malfunctioning in your page instantly; whether you find it as quickly is another question.

Here's the proper version of that code:

body {
   font-family: Helvetica, Arial, sans-serif; 
}

Solution: Keep at least part of your mind, and both of your eyes, on what you're typing as you go.

Missing a brace

Some of the most spectacularly bad "design breaks" I've seen have been caused by missing braces (this thing: { or } ). Often, the rest of the stylesheet fails to display, and your page magically becomes a catastrophic mess. Relax: the most spectacular "breaks" are usually the ones that are easiest to fix. Like this one.

Let's say you write this code:

body {
   font-family: Helvetica, Arial, sans-serif;
   <— Oops!
#wrap {
   width: 960px; 
}

Most likely, everything beginning with the #wrap rule is going to either go missing or be very wrongly implemented.

Solution: Again, keep a weather eye on what you're typing, and if you have a sudden, calamitous failure of your site, this is the first thing you should hunt for.

Missing a hash mark

The hex code for a color needs a hash mark. Leave it out, and your page won't display in the brilliant color you've chosen for it.

More about color.

Like this:

p {
   color: ea6bc2; <— Oops!
}

That "hashless" hex code won't display. Here's the right way to do it:

p {
   color: #ea6bc2;
}

Solution: Don't forget the hash mark.

Misspelled properties

Everyone has their problems with spelling something wrong. I'm an English teacher, and I make spelling errors all the time. People can usually figure out your sometimes-less-than-literate writing, but a computer can't. Remember, your fancy computer is no smarter than the table on which it sits. If you don't tell it precisely what to do, and spell your commands and content properly, the computer is too stupid to figure out what you were trying to spell.

div { 
   border-bototm: 5px; <— Oops!
}

What's a "bototm"? You don't know, I don't know, Glazebrook doesn't know (though it's his example), and neither does the computer.

Solution: A program like Notepad++ or Dreamweaver "color-codes" your code, making it easier to find your mistakes. (Don't be tempted by your word processor's spellchecker. It will choke on the code, and you might be tempted to actually save the file in that program, causing you a potential world of hurt.)

Misspelled values

Here's one of my favorites from Glazebrook's examples. See if you can find the misspelled value:

#wrap {
   padding: 10px 20pz 25px 20px; <— Oops!
}

So what are pz units? Glazebrook calls them "pizzles," to the great enjoyment of his readers. On the flip side, the misspelling causes the rule to fail and renders the whole kit and kaboodle invalid.

Solution: Nothing I know of, except caution.

Misspelled classes and IDs

Ever done this? I have.

#navigaiton { <— Oops!
   float: left;
}

The biggest problem is that you can use any string of letters as a class or ID name, so "navigaiton" is perfectly valid. However, chances are you won't remember the misspelling when you're typing it in your HTML pages, and a properly spelled <div id="navigation> won't match your misspelled CSS ID.

Improperly ordered values

CSS shorthand is a wonderful thing, as long as you remember to put the items in order properly.

If you do this, for example:

div {
   font: 2em Helvetica, Arial, sans-serif; 
}

a { 
   font: "Times New Roman", serif 1.5em; <— Oops!
}

the first rule works nicely, because the values are in the proper order. The second will result in problems and debugging.

Solution: Check this site's section on CSS shorthand for the proper way to order your values.

More about CSS shorthand.

Using improper characters in classes and IDs

Classes and IDs must start with a letter (a-z). They cannot start with a digit or a special character like a hyphen or an ampersand. Thusly:

.1example { <— Oops!
}

doesn't work, but this does:

.oneexample {
}

Solution: Nothing fancy, just make sure your class and ID names always start with letters.

Mixing cases

In a similar vein, mixing upper- and lower-case class and ID names doesn't work. CSS is case sensitive, so .oneExample is different from .oneexample. Thusly:

.oneexample {
}
 …
<div class="oneExample"> <— Oops!

doesn't match. This one does:

.oneexample {
}
 …
<div class="oneexample">

Solution: I advise using all lower-case lettering in your CSS, but other designers with better Web cred than I advise the use of upper- and lower-case lettering when appropriate. Whether you do or you don't, don't forget what's capitalized where. Sticking to lower-case lettering avoids this problem entirely.

Measurement values without units

Almost every measurement value in CSS needs a unit of measurement associated with it. This, for example:

#wrap { 
   margin: 3; <— Oops!
}

just confuses the browser. Pixels? Pizzles? Points? Inches? The browser won't guess, it will just throw a hairball.

There are two exceptions:

Zero

Zero never needs a unit of measurement.

Line heights

A line-height in your stylesheet doesn't need a unit of measurement. The selector line-height: 1.5 is interpreted as "one and one-half times my font size." In fact, while you can give units for line heights, you shouldn't. CSS guru Eric Meyer tells us why.

Solution: Remember to add units of measurement to your numerical values, unless you're writing a zero or a line height.

Competing identical rules

Any time you write a larger or more complex stylesheet, you'll run into this. You forget that you've set, say, your margin one way at the beginning of the sheet, and you set it differently for a particular element farther down. Like so:

ul li { 
   margin: 0 2em; 
}

... 300 lines later ... 

ul li { <— Oops!
   margin: 0; padding: 10px;
}

Because of CSS's cascading property, the latter rule overcomes the former, and your margins disappear in favor of your padding. Worse, when you try to fix the problem by tinkering with the first rule, nothing changes, and you get frustrated. Been there.

Solution: Keep your stylesheets well organized, and try to keep track of what you've set. When you're adding styles to particular elements, make sure that just those elements are styled, and not the whole enchilada by accident.

Unintentionally competing rules

Another "favorite" of more experienced designers who create more complex stylesheets. If you create a navigation list with the ID navigation and the class nav, you'd write the following HTML code:

<div id="navigation" class="nav">...</div>

If you forget, and set different values for the same rule at different times in your stylesheet, you run into trouble:

.nav {
   width: 50%; 
}

... later in the code ...

#navigation { <— Oops!
   width: 500px;
}

Want a fixed-width navigation bar? You just gave yourself one, even though you intended to set a flexible width.

Solution: Keep your stylesheets well organized, and try to keep track of what you've set. As in the previous example, when you're adding styles to particular elements, make sure that just those elements are styled, and not the whole enchilada by accident.

Calling a class an ID (or vice-versa)

How easy is this to do?

You write:

.navigation {
   float: left;
   width: 100%;
   height: 4em; 
}

and in your page you write:

<div id="navigation"> <— Oops!

Then you stare at your page, wondering why your carefully structured and styled navigation bar isn't displaying properly. You called it a class in your CSS and an ID in your HTML.

Solution: One of the best ways to handle this is to create a CSS/HTML template, where you use the same naming conventions (i.e. #navigation) on every site you create.

Using a nonexistent property

Sometimes the CSS terminology is, shall we say, counter-intuitive. Glazebrook gives an excellent example. Say you're flying through your coding, and you want to set your text size fairly large. You write:

body {
   text-size: 3em; <— Oops!
}

Makes sense, right? Unfortunately, there's no such CSS property as text-size. Maybe there should be, but there isn't.

Hester gives another example, presumably one that has vexed him in the past:

padding: auto;

Doesn't exist.

Solution: Code editors like Notepad++ or Dreamweaver, that use colors to highlight correct and incorrect code, help avoid these errors.

Using a nonexistent value

This is another favorite, and one similar to the one above. As sensible as this example may seem, it doesn't exist in CSS:

td {
   vertical-align: center; <— Oops!
}

It ought to work, but it doesn't. You want the value middle and not "center."

Solution: As above: Code editors like Notepad++ or Dreamweaver, that use colors to highlight correct and incorrect code, help avoid these errors.

Improperly matching properties and values

Sometimes even when you're right, you're wrong. See if you can spot what's wrong with the next example:

a {
   text-transform: italic; <— Oops!
}

Looks good, doesn't it? Well, it won't italicize your links. The text-transform property doesn't have a italic value. The font-style property does. Glazebrook notes:

[E]ven most advanced editors won't catch that bug, as you've used a perfectly reasonable property and value — you've just used them in an inappropriate combination.

Solution: Vigilance, sir and/or ma'am, constant vigilance.

Not closing comments

There's a problem with one of these code snippets. I've identified which one. Can you spot the glitch?

/* Navigation goes here. */
#nav {
   float: left;
   width: 100%;
   height: 3em; 
}

/* Navigation goes here. /* <— Oops!
#nav {
   float: left;
   width: 100%;
   height: 3em;
}

The only problem is in the closing of the second comment tag: /* doesn't close a comment properly. As a result, giant swaths of your CSS may suddenly stop working.

More about CSS comments.

Solution: Comments are an excellent way to organize your stylesheets. Just make sure you open and close them properly.

Using the z-index with the wrong element

More about the z-index.

The z-index only works if its host element has the position set for something besides static (the default).

In other words:

h1 {
   z-index: 1; <— Oops!
}

won't work, but this:

h1 {
   position: fixed;
   z-index: 1;
}

does work.

Solution: Don't include a z-index selector unless its element has its position designated, either in its own rule or in a parent element.

Using top, left, bottom, and right values properly

More about positioning.

Another positioning caveat: the top, left, bottom, and right values only apply to relatively or absolutely positioned elements. So this won't work:

h1 {
   position: fixed;
   direction: top; <— Oops!
}

but this will:

h1 {
   position: relative;
   direction: top;
}

HTML Mistakes

There's not as much here as there is above. That's not because there aren't that many errors to make in coding your HTML. Instead, most of the obvious ones are below, in the validating errors portion of this page. But here are some (yes, most of these will choke the validator, and yes, this is somewhat arbitrary):

Forgetting to close a tag

It's amazing how catastrophic an effect leaving off a little > can be to your code.

<p>content</p

Woops! That missing > will wreak havoc throughout your site. Trust me, I've done this too many times.

Sometimes we forget to close the tag entirely:

<div class="oops>
   <p:>content</p>

Notice something missing? That's right, the entire </div> tag is not there.

Improperly nesting tags

I've written a whole page on nesting tags:

More about nesting tags.

Just check that page, and keep your tags nested properly.

Forgetting to open or close quotes

The damage a little " can do … Remember, when you have a value, you need to surround it with opening and closing quotes, same as when you have opening and closing tags. This:

<img src="pic.jpg title="something" alt="something else">

is very, very easy to overlook, and can have unsightly effects on your design.

Jennifer Niederst Robbins reminds us:

Be careful not to leave out the closing quotation mark, or all the content from the opening quotation mark until the browser encounters a subsequent quotation mark will be interpreted as part of the value and won't display in the browser. This is a simple mistake that can cause hours of frustration.

Misusing the span element

More about div and span tags.

Many people misuse the span element, thinking that they can use it for everything from navigation to layouts. Roger Johannson calls it span mania. Don't do it.

Misusing the form tag

More about forms.

Forms are tricky enough without misusing them. The biggest mistake I see is forgetting that form is a block element:

More about block and inline elements.

Therefore, a form element will surround, say, a table or a paragraph, not vice-versa. This is proper:

<form>
   <table>
      <tr> ... </tr>
   </table>
</form>

Missing </body> or </html> tags

Again with the "if you open it, don't forget to close it" paradigm. This time you're forgetting to close the body of your page, or the entire HTML element. While browsers will often display the page more or less correctly even if you leave these off, the page won't validate, and problems may well ensue. Don't forget about them.

Using frames

Around the time the Clinton administration was finishing up (late '90s for you younger visitors), HTML frames were all the rage. Here's an example of a frame template, with all that pre-millennium goodness. Hmm, seems pretty useful at first glance. Why are frames so wrong? Well, here's an example from 1997 that told us back then just how much trouble frames could cause. This article, which I doubt is a whole lot newer, lists two "pros" and a good dozen "cons" of frameset HTML. Notice that I don't go into any detail about what frames are, how they work, and so forth. That's because you don't need to know. Frames are bad, frames are evil. Avoid them. And they're becoming obsolete anyway.

Validation Errors

More about validating your site.

By last count, there are approximately are a blue million validation errors that your site (or any site) can throw. Sometimes they "break" or disrupt your site's function, other times your site seems to work just fine until the evil W3 Validator weighs in. Here are some — just some — of the more common errors that can invalidate your site. (Much of the information in this site is cribbed from a list by Dynamic Site Solutions.)

Missing or misused alt attribute in the img tag

More about images.

This is a very common error. If you leave the alt attribute out of your img tag(s), your site will invalidate, and your visitors using screen readers will not be happy. This is an easy error to find and fix. You can read more about the alt attribute, and its sister attribute title, here.

Writing & instead of &

More about character entities.

Miswriting the "ampersand" as a character and not a character entity is another common error, and one often found in hyperlinks copied from other sources. (The links used on Amazon.com are stuffed with ampersands.) A few years ago, I was revamping one of my (now-defunct) sites, and validating a page gave me over 100 errors. I was horrified, until I realized that all but a very few were miswritten ampersands inside Amazon links.

Roger Johannson explains just how much trouble unescaped ampersands can cause.

Having more than one ID in a page

More about classes and IDs.

Another very common error. You can only have one ID per page, period. As a result, you should limit your use of this most powerful element to things like navigation and layout. Most browsers will render the page with multiple IDs anyway, but you won't validate, and worse, the ID problem may cause more problems down the line.

ID and/or class starting with a number

Can't be done; stick to IDs and classes beginning with letters. The browser usually won't recognize the element and that failure to recognize will wreak havoc among your page. If you need numbers in your IDs or classes, preface them with a letter, say:

#a2468 { }

Using deprecated HTML tags to center an element

Specifically, these two:

<center>
<div align="center"> </div>

They're obsolete, they're deprecated by HTML 4.01 standards, and in HTML Strict, they don't work. Period. I know there are many, many tutorials out there that advocate their use. Those tutorials have not been updated. Don't do it.

Missing DOCTYPE

More about DOCTYPEs.

Seriously. If you're any kind of burgeoning Web designer with any ambition of becoming skilled at any level, don't forget your DOCTYPE. It's the first thing I teach my middle school kids when they put together a page. They don't know what they are, but they know they must have them. Don't forget them.

In 2004, Molly E. Holzschlag :

The lack of DOCTYPE declarations in HTML and XHTML documents is very likely the most deadly of deadly markup sins.

It doesn't get much more fundamental than this.

Missing charset tags.

More about charsets.

Almost as bad as leaving out your DOCTYPE. Again, there's no excuse for leaving this out, and its lack can and will wreak havoc on your site. Get 'em in there!

Missing title element

Honestly, I don't know what happens if you leave these out. The world won't shift on its axis, dinosaurs won't rise out of the muck to attack the local Wal-Mart, but your site won't validate and it probably won't display right.

META elements outside the head

More about meta tags.

I honestly didn't know how common an error this was until I saw my students do it … over and over and over again. Those meta elements — titles, keywords, descriptions, charsets, all of them — go in the head of your document, not the body.

Placing code between the head and body elements

This is a no-man's land. Nothing can live (or at least function) in this space:

</head>
   Nothing should go here!
<body>

Placing code above the <html> or below the </html;> tags

Out of bounds. Sometimes the browser will render the code outside of these tags, but there's no guarantee it will work, and it will likely throw your page into complete chaos.