Friday, April 27, 2007

IE inherited margin bug: form elements and hasLayout

Internet Explorer on Windows has a wide variety of rendering bugs.
Many of these bugs can be worked around by giving affected elements
the IE-specific "hasLayout" property and an
analysis of how and when this works
is available. This article
describes the opposite situation: an IE rendering bug that is
triggered by elements having layout for which the workaround is to
remove the hasLayout property.

The bug is that certain form input elements whose containing box
has layout inherit the sum of the margins of all of their containing
boxes. Unlike the the well known
doubled float-margin bug
, this one does not involve floats. There
is a workaround but, so far, no magic-bullet CSS-only

The Problem

Consider this sample code:

.has-margins {
background-color: gray;
margin-left: 5em;
padding: 1em;

.has-layout {
background-color: tan;
width: 30em;

<form action="ignore">
<div class="has-margins">
<div class="has-layout">
INPUT tag, type=text:<br>
<input type="text"><br>
INPUT tag, type=checkbox:<br>
<input type="checkbox">

The outer has-margins box is gray and the full width of the page
except for a left margin of 5em. The inner has-layout box is tan,
30ems wide, and contains four lines of content: two of text and two
form elements. All four lines of content should be flush against the
left edge of the tan box.

Here is how it actually displays:

INPUT tag, type=text:

INPUT tag, type=checkbox:

For all CSS-enabled versions of IE/Win, including IE7, the
left edge of the text input field (the second line) is pushed
to the left. It incorrectly inherits the left margin of its
parent box because the parent has a width value, giving it

Consider another example which wraps a second has-margins box
around the inner has-layout box:

<form action="ignore">
<div class="has-margins">
<div class="has-margins">
<div class="has-layout">
INPUT tag, type=text:<br>
<input type="text"><br>
INPUT tag, type=checkbox:<br>
<input type="checkbox">

INPUT tag, type=text:

INPUT tag, type=checkbox:

The left edge of the has-layout box is correctly pushed twice as
far to the left (since both enclosing has-margins boxes have a left
margin). However, the affected input is now also pushed twice as far
to the left; compare its location to the text field in the previous
example. The form element actually inherits the the sum of
the left margins of all of its ancestors. Interestingly, it does not
inherit the top or bottom margins.

The bug seems to occur for all INPUT types except checkbox, radio,
and image as well as TEXTAREA elements but not for SELECT


The problem only seems to occur when the direct parent of the INPUT
element has hasLayout and any ancestor has margins. This leads to
several possible workarounds:

  • Set a negative margin on the INPUT element equal to the sum of all
    of its parents' margins. This is fine for static sites but if you are
    using a CMS it is probably not possible without scripting. Keep in
    mind that only some INPUT element types are affected; assigning
    negative margins to checkbox, radio, or image inputs will break your

  • Remove the margins from all ancestor elements. This is not
    particularly realistic.

  • Remove the hasLayout-granting style from the containing DIV.
    Since you presumably put that style there for a reason, this is also
    not particularly realistic.

  • Put inline text, a LABEL, or possibly any inline element at all
    immediately before the INPUT element. The fact that this solves the
    problem is probably why some people have not noticed it. Example:

    <form action="ignore">
    <div class="has-margins">
    <div class="has-layout">
    INPUT tag, type=text, preceeded by inline text:<br>
    Text: <input type="text"><br>

    INPUT tag, type=text, preceeded by inline text:


    Wrap the INPUT element in an unstyled SPAN, LABEL, or, in fact,
    any container element without a hasLayout-granting style. Example:
    <form action="ignore">

    <div class="has-margins">

    <div class="has-layout">
    INPUT tag, type=text, wrapped in an unstyled SPAN:<br>
    <span><input type="text"></span><br>




    INPUT tag, type=text, wrapped in an unstyled SPAN:

Tuesday, April 24, 2007


A great deal has been written about semantic markup and its importance. Some of this material has been written by purists who defend semantics because they like the logic and structure that semantic markup can convey. That’s all very well and good, but what does semantic markup mean? And what practical usage does it have?

Semantic means to have, or convey, meaning. In an Extensible/HyperText Markup Language (XHTML/HTML) context, this translates to using elements that actually convey accurate information about the content they enclose. If you have a page header or sub-header, it should be in an H tag (heading element). If you have a nice testimonial quote, it should be within blockquote element rather than basic paragraph tags with applied style. Remember the saying It does what it says on the box? Well, markup provides the boxes for all page content. Semantic markup ensures that your boxes have the right labels. It goes a long way to ensuring that software doesn’t have to open the box and analyse the contents first before figuring out how to render them. After all, if you open a can labeled “Beans,” you expect to see beans, not peaches. If can labeling was as variable as some of the page markup on the web, meal times would be a lot more… well, interesting, if not exactly edible.

Markup First, Style Later
When marking up new content, your first thought should be What kind of content is this phrase? and not What does this say? or How should it look? Concentrate on describing the content by applying the correct semantic markup first. Examine every piece of text on a page to determine what type of content it is and how best to convey that through markup. The humble p element should be your last resort — not your first choice.

Only when this process is complete should you start to look at graphical styling via your Cascading Style Sheet (CSS). If you have made good use of the full range of markup that is available — rather than just relying on p tags and the odd header element — you may even find that your pages are easier to style. You will probably end up with a larger set of elements to style on a single page and you may not have to create so many specific classes or ids to achieve a given effect.

Why Does Semantic Markup Make A Difference?

Well, for a start, you have no real idea how many of your visitors won’t actually see your pages using a graphical browser, so you can’t rely upon purely graphical renderings to convey meaning. Styling your quotes using p tags with added styling to render the text dark red or bright green is pretty pointless if some of your visitors won’t ever see the pretty effect. Google certainly won’t, and that’s one pretty important visitor.

However, from an accessibility point of view, a great deal of the assistive technology out there is reliant upon semantic markup. The assumption is that headings will be in enclosed in H tags; quotations will be marked up properly and lists will use list markup and not just rely on hard-coded line breaks.
JAWS, for example offers users the option to jump from header to header without reading the intervening text. This is the audio equivalent of a sighted user scanning a page to see what topics it includes before settling down to read a particular paragraph. However, this feature is useless if a page doesn’t contain any header markup. That line of text at the top of a page may look like a header but, unless it’s marked up correctly, it’s not a header and it certainly won’t sound like one.

Similarly, some screen readers may automatically change voice when encountering quotations that are correctly identified using markup. If you don’t use appropriate quotation markup, it becomes extremely difficult to separate, for example, testimonials, from their surrounding text. Conversely, if you use blockquote inappropriately to simply indent plain text, screen reader users may be presented with a page that no longer makes sense.
Finally, using semantic markup offers the best method of future proofing your content and ensuring that it continues to make sense via a whole range of user agents now or in the future.

Different Strokes

Although adopting semantic markup will, by definition, tend to lead you towards particular approaches and practices, it is worth bearing in mind that there may not be a hard and fast rule in every situation. Even within semantic markup, there is room for a number of equally valid Best Practice approaches. For example, should a page have just one H1 heading element or is it okay to have more than one? There are good arguments for both sides of that particular discussion.

Right and wrong are concepts that should only have limited usage within web design once you get beyond the appropriate World Wide Web Consortium (
W3C) specifications. Beyond these documents, there is only opinion and user feedback. The latter is particularly important and should never be under-estimated. Given that web pages are supposedly intended for use by users, this does seem to be stating the obvious but there are times when user feedback can get over-looked in the pursuit of semantic perfection. And that just has to be plain wrong!

Opinions, however, are just that. They are not rules and they are open to discussion. Listen to as many points of view as you can, then think about it on your own until you reach your own informed decision. At the end of the day, that’s what applying semantic markup is really all about — thinking about your content first.

Monday, April 23, 2007

navigation matrix reloaded

How it works

At first this example might not seem very different from other navigation experiments. But the most interesting part is hidden in the code and the methodology. My example is called navigation matrix because it actually loads a matrix to display the correct graphics for the menu items. Below I included the image that is downloaded — just once.

As you can see it contains all the different states required for the navigation to function properly. In essence it’s based on the method to shift background positions, which of course works faster than shifting individual images. By assigning a specific id to each body tag in individual pages I can target the list elements and set their respective backgrounds. The only thing I need to do is make sure that the background is in the right position for each element.

The first 4 rows are used for the different ul backgrounds. As you can see they perfectly match with the hover states on the individual pages. The other two rows include the other states I need for the navigation to function properly. Of course some tabs are included more than once, but this is needed because I need the entire row to display as the ul background, instead of just individual elements. The size in kilobytes is exactly the same as the previous matrix.

The HTML is given below

<body id="welcome">
<div id="header">
<ul id="nav">
<li id="wel"><a href="welcome2.html">welcome</a></li>
<li id="pro"><a href="products2.html">products</a></li>
<li id="sup"><a href="support2.html">support</a></li>
<li id="con"><a href="contact2.html">contact</a></li>

The css is

body {
background: #f1efe2;

#header {
margin: 0 auto 0 auto;
width: 650px;
padding: 0;
border: 5px solid #fff;
height: 120px;
background: #666 url(header.png) no-repeat left top;

ul#nav {
position: relative;
top: 68px;
left: 188px;
width: 346px;
margin: 0;
height: 22px;
list-style-type: none;
overflow: hidden;

body#welcome ul#nav
{ background: transparent url(nav_f_2.png) no-repeat 0 0; }
body#products ul#nav
{ background: transparent url(nav_f_2.png) no-repeat 0 -22px; }
body#support ul#nav
{ background: transparent url(nav_f_2.png) no-repeat 0 -44px; }
body#contact ul#nav
{ background: transparent url(nav_f_2.png) no-repeat 0 -66px; }

ul#nav li a {
position: absolute;
top: 0;
width: 84px;
text-indent: -9000px;
text-decoration: none;
padding: 22px 0 0 0;
overflow: hidden;
height: 0px !important;
height /**/:22px; /* IE5/Win */
background: transparent url(nav_f_2.png) no-repeat;

body#welcome li#wel a
{ background-position: 0 0; width: 94px; left: 0; }
body#welcome li#wel a:hover
{ background-position: 0 0; }
body#welcome li#pro a
{ background-position: -94px -88px; left: 94px; }
body#welcome li#pro a:hover
{ background-position: -94px 0px; }
body#welcome li#sup a
{ background-position: -178px -88px; left: 178px; }
body#welcome li#sup a:hover
{ background-position: -178px 0; }
body#welcome li#con a
{ background-position: -262px -88px; left: 262px; }
body#welcome li#con a:hover
{ background-position: -262px 0; }

body#products li#wel a
{ background-position: 0 -110px; width: 94px; left: 0; }
body#products li#wel a:hover
{ background-position: 0 -22px; }
body#products li#pro a
{ background-position: -94px -22px; left: 94px; }
body#products li#pro a:hover
{ background-position: -94px -22px; }
body#products li#sup a
{ background-position: -178px -88px; left: 178px; }
body#products li#sup a:hover
{ background-position: -178px 0; }
body#products li#con a
{ background-position: -262px -88px; left: 262px; }
body#products li#con a:hover
{ background-position: -262px 0; }

body#support li#wel a
{ background-position: 0 -88px; width: 94px; left: 0; }
body#support li#wel a:hover
{ background-position: 0 -44px; }
body#support li#pro a
{ background-position: -94px -110px; left: 94px; }
body#support li#pro a:hover
{ background-position: -94px -44px; }
body#support li#sup a
{ background-position: -178px -44px; left: 178px; }
body#support li#sup a:hover
{ background-position: -178px -44px; }
body#support li#con a
{ background-position: -262px -88px; left: 262px; }
body#support li#con a:hover
{ background-position: -262px 0; }

body#contact li#wel a
{ background-position: 0 -88px; width: 94px; left: 0px; }
body#contact li#wel a:hover
{ background-position: 0 -44px; }
body#contact li#pro a
{ background-position: -94px -88px; left: 94px; }
body#contact li#pro a:hover
{ background-position: -94px 0; }
body#contact li#sup a
{ background-position: -178px -110px; left: 178px; }
body#contact li#sup a:hover
{ background-position: -178px -66px; }
body#contact li#con a
{ background-position: -262px -66px; left: 262px; }
body#contact li#con a:hove
r { background-position: -262px -66px; }

p { text-align: center; }
p a
{ color: #666; text-decoration: none; font: 11px/1.5 tahoma, arial, verdana, sans-serif; }
p a em
{ font-style: normal; border-bottom: 1px solid #999; }
p a:hover em
{ color: #333; border-bottom: 0; }

you can see the navigation tab here

css- tab navigation

here is the code for a css tab navigation.

<html xmlns="" xml:lang="en" >
<meta http-equiv="content-type" content="application/xhtml+xml; charset=iso-8859-1" />
<meta name="author" content="Didier Hilhorst" />
<title>CSS Based Navigation</title>
<style media="all" type="text/css">

body {
margin: 26px;
padding: 0;
background: #fff url(back.png) no-repeat;

span {
display: none;

ul {
position: relative;
width: 800px;
background: url(bg_nav.png) no-repeat;
height: 113px;
list-style-type: none;
margin: 0;
padding: 0;

li#bu1 a, li#bu2 a, li#bu3 a, li#bu4 a {
background: transparent;
position: absolute;
width: 110px;
height: 32px;
bottom: 0;
text-decoration: none;

/* adjusted values for IE6 */
* html*li#bu1 a, * html*li#bu2 a, * html*li#bu3 a, * html*li#bu4 a { bottom: -1px; }

li#bu1 a { left: 21px; }
li#bu2 a { left: 122px; background: url(business_hover.gif) 0 0 no-repeat; }
li#bu3 a { left: 223px; background: url(personal_hover.gif) 0 0 no-repeat; }
li#bu4 a { left: 324px; background: url(information_hover.gif) 0 0 no-repeat; }

li#bu2 a:hover, li#bu3 a:hover, li#bu4 a:hover { background-position: 0 -32px; }


<li id="bu1"><a href="#"><span>homepage</span></a></li>
<li id="bu2"><a href="#"><span>business</span></a></li>

<li id="bu3"><a href="#"><span>personal</span></a></li>
<li id="bu4"><a href="#"><span>information</span></a></li>

Friday, April 20, 2007

sticky footer

here is the XHTML markup

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ""&gt;<html xmlns="" xml:lang="en"> <head>
<title>A CSS Sticky Footer</title>
<!-- The second stylesheet is to make things look pretty. The first one is only the important one. -->
<link rel="stylesheet" type="text/css" media="screen" href="layout.css" /> <link rel="stylesheet" type="text/css" media="screen" href="style.css" />
</head> <body>
<div class="wrapper">
<div class="header"> <h1>CSS Sticky Footer</h1> </div>
<h2>A CSS sticky footer that just works</h2> <img src="browsers.gif" width="127" height="122" alt="Browser Icons" /> <p>We've all tried to use a <strong>sticky footer</strong> one time or another, but they never seem to come out right, do they? Well, the days of a hard to understand CSS-based <strong>sticky footer</strong> are thankfully over. In just a few simple CSS classes with minimal extra HTML markup, I've fashioned a <strong>sticky footer</strong> that even beginners can get a handle on. It's been tested in IE 5 and up, Firefox, Safari and Opera.</p> <h2>Usage of the CSS</h2> <p><q>Great! this is exactly what I'm looking for! Can I use it?</q></p> <p>Absolutely. There are no terms, licenses, fees or requirements. Use it as you will. If you find the kindness to link to me on your site, I'd appreciate it, but it's by no means necessary. Have fun, and don't be afraid to ask me any questions or send me your thoughts.</p> <p class="download"><a href="layout.css">View the CSS</a> or <a href="sticker.txt">download the HTML</a></p>
<div class="push"></div>
<div class="footer"> <p>Copyright © 2006-2007 Ryan Fait All rights reserved.<br /> You may not reproduce this example without written permission from Ryan Fait</p> </div>
<script type="text/javascript" src=""></script>; <script type="text/javascript"> _uacct = "UA-271290-1"; urchinTracker(); </script>

here is the CSS

STICKER - A valid, easy to use CSS sticky footer by Ryan Fait
This is the basic CSS you need along with the one extra emptydiv and the wrapper required to achieve the effect. I suggestthat you leave the * { margin: 0; } code in while testing andbuilding your site because margins do have a tendency to messthings up a bit. Have fun!
Copyright (c) 2006-2007 Ryan Fait

* { margin: 0;}html, body { height: 100%;}.wrapper { min-height: 100%; height: auto !important; height: 100%; margin: 0 auto -4em; /* the bottom margin is the negative value of the footer's height */}.footer, .push { height: 4em; /* .push must be the same height as .footer */}

I've received a few comments about vertical margins causing afew problems with the layout. If you want space betweenparagraphs or headers, use padding instead of margin. It's assimple as that.

Rounded Corner Boxes the CSS3 Way

If you’ve been doing CSS for a while you’ll know that there are approximately 3,762 ways to create a rounded corner box. The simplest techniques rely on the addition of extra mark-up directly to your page, while the more complicated ones add the mark-up though DOM manipulation. While these techniques are all very interesting, they do seem somewhat of a kludge. The goal of CSS is to separate structure from presentation, yet here we are adding superfluous mark-up to our code in order to create a visual effect. The reason we are doing this is simple. CSS2.1 only allows a single background image per element.

Thankfully this looks set to change with the addition of multiple background images into the CSS3 specification. With CSS3 you’ll be able to add not one, not four, but eight background images to a single element. This means you’ll be able to create all kinds of interesting effects without the need of those additional elements.

While the CSS working group still seem to be arguing over the exact syntax, Dave Hyatt went ahead and implemented the currently suggested mechanism into Safari. The technique is fiendishly simple, and I think we’ll all be a lot better off once the W3C stop arguing over the details and allow browser vendors to get on and provide the tools we need to build better websites.

To create a CSS3 rounded corner box, simply start with your box element and apply your 4 corner images, separated by commas.

.box {
background-image: url(top-left.gif), url(top-right.gif), url(bottom-left.gif), url(bottom-right.gif);

We don’t want these background images to repeat, which is the normal behaviour, so lets set all their background-repeat properties to no-repeat.

.box { background-image: url(top-left.gif), url(top-right.gif), url(bottom-left.gif), url(bottom-right.gif); background-repeat: no-repeat, no-repeat, no-repeat, no-repeat; }

Lastly, we need to define the positioning of each corner image.

.box { background-image: url(top-left.gif), url(top-right.gif), url(bottom-left.gif), url(bottom-right.gif); background-repeat: no-repeat, no-repeat, no-repeat, no-repeat; background-position: top left, top right, bottom left, bottom right; }

And there we have it, a simple rounded corner box with no additional mark-up.
As well as using multiple background images, CSS3 also has the ability to create rounded corners without the need of any images at all. You can do this by setting the border-radius property to your desired value as seen in the next example.

.box { border-radius: 1.6em; }

Setting Type on the Web to a Baseline Grid

We web designers get excited about the littlest things. Our friends in the print world must get a kick out of watching us talk about finally being able to achieve layouts on the web that they’ve taken for granted for years. Let’s face it: it’s easier these days to embed a video on the web than it is to set type consistently or align elements to a universal grid.

But we’re scrappy folks, web designers. We don’t give up easy. In the long slow battle with browser support and platform inconsistencies, we’ve been able to bring more and more sophisticated print techniques onto the web—sometimes kicking and screaming.

We have the technology

Over the last year or so, there’s been a lot of talk about grid systems and using column grids for website layouts. Mark gave us a
lesson plan, Khoi gave us a case study and Cameron gave us a toolkit. The message is clear: we have the browser support, the know-how, and the tools we need to create consistent multi-column grid layouts on the web.
We can apply the same principles of proportion and balance to the type within those columns by borrowing another technique from our print brethren: the baseline grid.
The main principle of the baseline grid is that the bottom of every line of text (the baseline) falls on a vertical grid set in even increments all the way down the page. Imagine those old
Big Chief ruled writing pads they gave you in grade school to practice penmanship and you’ve got the basic idea. The magical end result is that all the text on your page lines up across all the columns, creating a harmonious vertical rhythm.
In print, it’s not that hard. Just enable the baseline grid in Quark or InDesign and set the increment based on the line-height you want. On the web of course, it’s another story. It’s hard enough to align things vertically with CSS because it’s tough to predict where every element will fall, and it only gets worse when we’re dealing with type, which is hard enough to size consistently on its own. But with a little math and a slightly obsessive attention to detail, we can make it work.

Firing up the grid

Note: I’ve used pixel units for sizing text in the examples for this article. Recognizing that this may be a surprising recommendation for an article in this publication, I’ve addressed some of my reasons for doing so—as well as some alternate techniques that use relative units—further down.

The first thing we have to do is set a line-height for our grid. I’ve chosen a pretty standard base font size of 12 pixels, and set the line-height at 18 pixels, which gives us a nice open leading of about 150%. It’s important to think about your line-heights up front. You want a ratio of font size to line-height that’s a good balance for readability and that’s easily divisible into smaller units (more on this later).

I’ve also borrowed a trick from
Khoi and created a tiling background image that I can use on the page while I’m working to make sure everything lines up where I want it to. You can see the end result with the grid turned on in this example.

You’ll notice in the previous example that the text doesn’t fall directly on the grid lines. Because of the way CSS renders line-height (by adding space above and below the letters) it’s a lot easier to line the text up within the grid lines rather than directly on them. It’s possible to adjust your background image to take this into account, or tweak the padding on certain elements so the text starts in a different place, but there’s no point making this more complicated than it needs to be.

Paragraphs and headers

I’ll start by resetting the margin and padding on everything to zero so we don’t have to worry about default browser styles. In practice, you’ll probably want to use something a little more precise, but for the purposes of this example, a good old star selector will do just fine.

* {
margin: 0;
padding: 0;

We want space between paragraphs, but the default top and bottom margins of 1em (which works out in this case to 12 pixels) won’t work with our 18 pixel grid, so we’ll set the bottom margin on paragraphs to 18 pixels.

p {
margin-bottom: 18px;

As we set the font size for headers, we also need to set appropriate line-heights in multiples of 18, as well as adding the 18 pixel bottom margin.

h1 {
font-size: 24px;
line-height: 36px;
margin-bottom: 18px;

h2 {
font-size: 18px;
line-height: 18px;
margin-bottom: 18px;

h3 {
font-size: 12px;
line-height: 18px;

The pattern is pretty simple. Any time you add vertical space with a margin or padding, you need to add it in units of 18 pixels to maintain the baseline grid. You don’t always have to add it in one place, but you need to add it in pairs that add up to 18 pixels. For instance, you could set a top margin of 12 pixels and a bottom margin of 6 pixels.


Lists are a little bit tougher. We’re used to adding a little padding between each list item and before or after a nested list. Depending on your grid size, you may have to choose between adding a lot of extra space (adding a full grid line) or adding none at all and letting list items fall on the regular grid lines.
Since the 18-pixel line-height we started with is pretty generous, the “none at all” option works pretty well here. I’ll just add the bottom margin of 18 pixels.

ul, ol {
margin-bottom: 18px;

As for nested lists, it’s possible to add half of your line-height (in this case, 9 pixels) of margin above and below nested lists. Adding half a line to the top and another half to the bottom means the contents of the list will be “off the grid,” but the grid will get back on track once the list ends. It’s a compromise, but sometimes worth it for designs in which you need to accommodate especially long or complicated nested lists.

Floats and sidebars

Here’s where a little discipline comes in. Images and other elements floated within your text need to be sized vertically in multiples of your grid increment: in this case, multiples of 18. If they’re sized correctly, you can add margins around them that add up vertically to a multiple of 18, and the text will always break in the right place, directly under your image.

.left {
float: left;
margin: 0 18px 18px 0;
.right {
float: right;
margin: 0 0 18px 18px;

Other floated elements like callout boxes are a little bit more complicated, since it’s harder to predict their height based on the content inside. As long as all text and images inside the float follow the 18-pixel rules, and you always add vertical padding and margins in groups that add up to 18, everything should line up no matter what you put inside.

.callout {
border: 1px solid #ddd;
padding: 8px 10px;
margin-bottom: 18px;

Notice that I added 8 pixels of padding to the top and bottom of the floated element, since the border width already accounted for 2 pixels of added height (8 + 8 + 1 + 1 = 18).
I’m also going to suck out the bottom margin on the last element in the callout so we don’t end up with too much extra space inside. This isn’t a critical layout feature (the grid is still intact without it), so I’ll go ahead and use the :last-child pseudo class since it doesn’t require me to add any extra markup. IE6 won’t get it, but it won’t break the layout.

.callout :last-child {
margin-bottom: 0;

The important thing to remember with callouts and sidebars is to keep the line-height the same even if you make the text smaller. You might be tempted to tighten it up, but even for 11- or 10-pixel font sizes, 18 pixels is still a very readable line-height.

All your baseline are belong to us

You can see it all put together in this example. If you don’t believe me, put your rulers away and check it out with the background grid visible.

You can start to see why baseline grids aren’t used very often on the web. It’s pretty tough to keep up with it—especially as your layouts get more complicated—and we’ve only touched the surface of some of the relatively manageable challenges. Just as in print, baseline grids are not always the right choice for every layout, and sometimes you need to make exceptions or exclude certain elements from the grid to make a layout work.

But it’s definitely possible, and something that’s worth experimenting with, especially in combination with a horizontal or column grid. A nice balanced baseline grid—even just within the main content area—can add polish and readability as we move typesetting on the web to the next generation with CSS3 and beyond.

Don’t fear the pixel

One final note on font sizing: I’m using pixels instead of ems in this example for one reason: it makes everything simpler. With pixels, I can set one base line-height for the entire document and I don’t have to recalculate it whenever I use a smaller font size. When designing a practical system like this, it’s important that it’s relatively easy (for yourself and others) to use and maintain.

You can use relative sizes, but it quickly becomes a lot more difficult to maintain as the math becomes more complicated. It’s easy to get 12 out of 18 (just set the line-height to 1.5em), but when you want to adjust the text size but keep the same line-height, the fractions start to get messy, and predicting how browsers are going to round your values makes it hard to be exact. It’s certainly possible however, and if you’re interested in trying something similar with relative text sizes, I’d recommend checking out Richard Rutter’s excellent
24 ways article, Compose to a Vertical Rhythm.

In the end, it’s a tradeoff. Most browsers will scale pixel-based line-heights proportionally along with the text. Of course, the margins don’t scale, and neither do the images. But is it worth making the system more complicated just to make the margins scale if the images don’t? It depends on the situation. In the end, it’s up to you.

At some point as designers we have to strike a balance between creating pixel-perfect layouts and infinitely flexible ones. When you get down to it, resizable text is primarily an accessibility feature, not a design feature. Ideally it’s something that should be provided by the browser, no matter how the page is built, and in modern browsers it is. As long as all your content is readable and accessible at all sizes, it’s not necessarily true that the design must maintain integrity as you scale.

Breadcrumb Navigation Increasingly Useful

Not all design decisions are a matter of website survival. Of course, it's important to get the big things right, or you won't have any users. But getting the small things right enhances usability and fosters user comfort. A perfect example here is the breadcrumb trail.

Breadcrumbs won't help a site answer users' questions or fix a hopelessly confused information architecture. All that breadcrumbs do is make it easier for users to move around the site, assuming its content and overall structure make sense. That's sufficient contribution for something that takes up only one line in the design.
Breadcrumbs have always been a secondary navigation aid. They share this humble status with site maps. To navigate, site visitors mainly use the primary menus and the search box, which are certainly more important for usability. But from time to time, people do turn to the site map or the breadcrumbs, particularly when the main navigation doesn't quite meet their needs.

Despite their secondary status, I've recommended breadcrumbs since 1995 for a few simple reasons:
Breadcrumbs show people their current location relative to higher-level concepts, helping them understand where they are in relation to the rest of the site.
  • Breadcrumbs afford one-click access to higher site levels and thus rescue users who parachute into very specific but inappropriate destinations through search or deep links.
  • Breadcrumbs never cause problems in user testing: people might overlook this small design element, but they never misinterpret breadcrumb trails or have trouble operating them.
  • Breadcrumbs take up very little space on the page.

So, despite the merely mid-sized benefits, the overall cost-benefit analysis comes out quite strongly in favor of breadcrumbs. Their downside is incredibly small: while they do take up space, that space is minute. When you divide a mid-sized numerator by a tiny denominator, the resulting fraction is substantial.

The main argument against breadcrumbs is that many users overlook them. So, why do something that only benefits a minority?

As I've long argued, breadcrumbs are different than most other little-used design elements for the simple reason that they don't hurt users who ignore them.

Growing Popularity

The case against breadcrumbs is crumbling. Every year we see more people use breadcrumbs in our studies. Because breadcrumbs are not important enough for a dedicated study, I don't have an exact number for the current percentage of breadcrumb users. But it's definitely growing over time.

In testing an e-commerce site last month, for example, one user complained: "This is missing a feature to go back to the previous page."

I found this apparent request for a Back button puzzling, since the button was featured prominently in the browser and the person had easily used it earlier in the test session. Also, for six years, it's been an established guideline to avoid duplicating browser functionality in the page design.

It quickly became clear, however, that the user wasn't asking for a duplicate Back button. Elaborating on the previous complaint, she pointed to the place on the page where breadcrumbs typically appear and said she wanted the list of links to higher-level pages.
In other words, the user wanted breadcrumbs. She'd seen them before, but didn't know what they were called, so she asked for them using words that -- if taken literally -- would have been easily misinterpreted.

This is a great example of the hard-won lesson of usability: don't comply with user requests. Give more attention to what study participants do than to what they say.

Consistency Breeds Familiarity

Human behavior doesn't change much over the years. My recent book documents a few cases where Web design guidelines from the mid-1990s have changed. But mainly, usability guidelines stay the same decade after decade.

Why are people now using breadcrumbs to the extent that they actually miss them when sites don't offer them?

It's exactly because of breadcrumbs' modest nature that people are becoming accustomed to them. There aren't too many ways to mess up breadcrumbs in a design. No fancy stuff, just a line of textual links.

Breadcrumbs are almost always implemented the same way, with a horizontal line that
progresses from the highest level to the lowest, one step at a time;
starts with the homepage and ends with the current page;

has a simple text link for each level (except for the current page, because you should never have a link that does nothing); and

has a simple, one-character separator between the levels (usually ">"). This consistency means that people know a breadcrumb trail when they see one, and immediately know how to use it. Consistency breeds familiarity and predictability, which breed usability. This again means that you must comply with conventions in the design of your own breadcrumbs.

Breadcrumbs are also useful for intranets: 80% of this year's award-winning intranets use breadcrumbs.

Hierarchy or History?I'm sometimes asked whether website breadcrumbs should follow the fairytale model of Hansel and Gretel. In that story, the children walk through a bewildering forest, dropping breadcrumbs behind them in hopes that they might later find their way out.
In user interface design, it's often dangerous to take metaphors too far, and breadcrumbs are again the perfect example. Offering users a Hansel-and-Gretel-style history trail is basically useless, because it simply duplicates functionality offered by the Back button, which is the Web's second-most-used feature.

A history trail can also be confusing: users often wander in circles or go to the wrong site sections. Having each point in a confused progression at the top of the current page doesn't offer much help.

Finally, a history trail is useless for users who arrive directly at a page deep within the site. This scenario is when breadcrumbs show their greatest usability benefit, but only if you implement them correctly -- as a way to visualize the current page's location in the site's information architecture.

Breadcrumbs should show the site hierarchy, not the user's history.
For non-hierarchical sites, breadcrumbs are useful only if you can find a way to show the current page's relation to more abstract or general concepts. For example, if you allow users to winnow a large product database by specifying attributes (of relevance to users, of course), the breadcrumb trail can list the attributes that have been selected so far. A toy site might have breadcrumbs like these: Home > Girls > 5-6 years > Outdoor play (note that the links should be colored as well as underlined, but I don't do this here to avoid confusion with these dummy links).

Looking ahead, people will use breadcrumbs even more because they're an important navigation tool in Windows Vista. Most users don't distinguish clearly between the operating system, applications, and content or websites. Users will thus transfer their understanding of Vista's interaction techniques to your website.

If you don't have breadcrumbs, it's time to start planning for them. They'll improve your usability a bit now, meet increasing user expectations in the future, and -- most importantly -- they won't hurt.

Thursday, April 19, 2007

css for table

Here is the HTML for table

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
< html xmlns="">
< head>
< meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
< title>CSS Tables< /title>
< link href="styles.css" rel="stylesheet" type="text/css" />
< /head>
< body>
< table id="mytable" cellspacing="0" summary="The technical specifications of the Apple PowerMac G5 series">
< caption>Table 1: Power Mac G5 tech specs < /caption>
< tr>
< th scope="col" abbr="Configurations" class="nobg">Configurations< /th>

< th scope="col" abbr="Dual 1.8">Dual 1.8GHz< /th>
< th scope="col" abbr="Dual 2">Dual 2GHz< /th>
< th scope="col" abbr="Dual 2.5">Dual 2.5GHz< /th>
< /tr>
< tr>
< th scope="row" abbr="Model" class="spec">Model< /th>
< td>M9454LL/A< /td>

< td>M9455LL/A< /td>
< td>M9457LL/A< /td>
< /tr>
< tr>
< th scope="row" abbr="G5 Processor" class="specalt">G5 Processor< /th>
< td class="alt">Dual 1.8GHz PowerPC G5< /td>
< td class="alt">Dual 2GHz PowerPC G5< /td>

< td class="alt">Dual 2.5GHz PowerPC G5< /td>
< /tr>
< tr>
< th scope="row" abbr="Frontside bus" class="spec">Frontside bus< /th>
< td>900MHz per processor< /td>
< td>1GHz per processor< /td>
< td>1.25GHz per processor< /td>

< /tr>
< tr>
< th scope="row" abbr="L2 Cache" class="specalt">Level2 Cache< /th>
< td class="alt">512K per processor< /td>
< td class="alt">512K per processor< /td>
< td class="alt">512K per processor< /td>
< /tr>

< /table>

< p>< a href="styles.css">→ download stylesheet< /a>< /p>
< /body>
< /html>

And this is the CSS

body {
font: normal 11px auto "Trebuchet MS", Verdana, Arial, Helvetica, sans-serif;
color: #4f6b72;
background: #E6EAE9;

a {
color: #c75f3e;

#mytable {
width: 700px;
padding: 0;
margin: 0;

caption {
padding: 0 0 5px 0;
width: 700px;
font: italic 11px "Trebuchet MS", Verdana, Arial, Helvetica, sans-serif;
text-align: right;

th {
font: bold 11px "Trebuchet MS", Verdana, Arial, Helvetica, sans-serif;
color: #4f6b72;
border-right: 1px solid #C1DAD7;
border-bottom: 1px solid #C1DAD7;
border-top: 1px solid #C1DAD7;
letter-spacing: 2px;
text-transform: uppercase;
text-align: left;
padding: 6px 6px 6px 12px;
background: #CAE8EA url(images/bg_header.jpg) no-repeat;

th.nobg {
border-top: 0;
border-left: 0;
border-right: 1px solid #C1DAD7;
background: none;

td {
border-right: 1px solid #C1DAD7;
border-bottom: 1px solid #C1DAD7;
background: #fff;
padding: 6px 6px 6px 12px;
color: #4f6b72;

td.alt {
background: #F5FAFA;
color: #797268;

th.spec {
border-left: 1px solid #C1DAD7;
border-top: 0;
background: #fff url(images/bullet1.gif) no-repeat;
font: bold 10px "Trebuchet MS", Verdana, Arial, Helvetica, sans-serif;

th.specalt {
border-left: 1px solid #C1DAD7;
border-top: 0;
background: #f5fafa url(images/bullet2.gif) no-repeat;
font: bold 10px "Trebuchet MS", Verdana, Arial, Helvetica, sans-serif;
color: #797268;

Wednesday, April 18, 2007

show-hide DIV

suppose there are 10 divs in a page. you need to show each div while clicking the corresponding link

here is the

<script language="javascript" type="text/javascript" >
function showdiv(id)
{ for (var x = 1; x <= 10; x++)
var a='div_' + x;
document.getElementById(a).style.display = "none"
document.getElementById("div_" + id).style.display = ""
function hidediv ( id )
document.getElementById("div_" + id ).style.display = "none"

and call the javascript inside an anchor tag like this onClick=showdiv(1)

Wednesday, April 4, 2007

Javascript for show-hide Div

Shown below is the function for showing and hiding two div containers

The function showHideDiv has two variables for passing the values for which div has to show and which div has to hide.

function showHideDiv(divToShow, divToHide)

document.getElementById(divToShow).style.display = "block";
document.getElementById(divToHide).style.display = "none";

Call the function as shown below.divToShow has to replaced by the ID of the div tag to be shown and divToHide has to replaced by the ID of the div tag to hide.

('divToShow','divToHide');">Protection Area

Monday, April 2, 2007

Deep Linking is Good Linking

Links that go directly to a site's interior pages enhance usability because, unlike generic links, they specifically relate to users' goals. Websites should encourage deep linking and follow three guidelines to support its users.

Supporting Deep-Link Users

A website is like a house with a million entrances: the front door is simply one among many ways to get in. A good website will accommodate visitors who choose alternate routes.
Here are three guidelines for enhancing usability for users who enter your site at interior pages:

Tell users their arrival point, and how they can proceed to other parts of the site by including these three design elements on every single page:
Company name or logo in upper left corner
Direct, one-click link to the homepage
Search (preferably in the upper right corner)

Orient the user relative to the rest of the website. If the site has hierarchical information architecture, a breadcrumb trail is usually the best way to do this. Also, include links to other resources that are directly relevant to the current location. Don't bury the user in links to all site areas or to pages that are unrelated to their current location.

Don't assume that users have followed a drill-down path to arrive at the current page. They may not have seen information that was contained on higher-level pages.

Top Ten Guidelines for Homepage Usability

A company's homepage is its face to the world and the starting point for most user visits. Improving your homepage multiplies the entire website's business value, so following key guidelines for homepage usability is well worth the investment.
Homepages are the most valuable real estate in the world. Each year, companies and individuals funnel millions of dollars through a space that's not even a square foot in size. For good reason. A homepage's impact on a company’s bottom line is far greater than simple measures of e-commerce revenues: The homepage is your company's face to the world. Increasingly, potential customers will look at your company's online presence before doing business with you -- regardless of whether they plan to close the actual sale online.

The homepage is the most important page on most websites, and gets more page views than any other page. Of course, users don't always enter a website from the homepage. A website is like a house in which every window is also a door: People can follow links from search engines and other websites that reach deep inside your site. However, one of the first things these users do after arriving at a new site is go to the homepage. Deep linking is very useful, but it doesn't give users the site overview a homepage offers -- if the homepage design follows strong usability guidelines, that is.
Following are ten things you can do to increase the usability of your homepage and thus enhance your website's business value.

Make the Site's Purpose Clear: Explain Who You Are and What You Do

1. Include a One-Sentence Tagline

Start the page with a tagline that summarizes what the site or company does, especially if you're new or less than famous. Even well-known companies presumably hope to attract new customers and should tell first-time visitors about the site's purpose. It is especially important to have a good tagline if your company's general marketing slogan is bland and fails to tell users what they'll gain from visiting the site.

2. Write a Window Title with Good Visibility in Search Engines and Bookmark Lists

Begin the TITLE tag with the company name, followed by a brief description of the site. Don't start with words like "The" or "Welcome to" unless you want to be alphabetized under "T" or "W."

3. Group all Corporate Information in One Distinct Area

Finding out about the company is rarely a user's first task, but sometimes people do need details about who you are. Good corporate information is especially important if the site hopes to support recruiting, investor relations, or PR, but it can also serve to increase a new or lesser-known company's credibility. An "About " section is the best way to link users to more in-depth information than can be presented on the homepage.

Help Users Find What They Need

4. Emphasize the Site's Top High-Priority Tasks

Your homepage should offer users a clear starting point for the main one to four tasks they'll undertake when visiting your site.

5. Include a Search Input Box

Search is an important part of any big website. When users want to search, they typically scan the homepage looking for "the little box where I can type," so your search should be a box. Make your search box at least 25 characters wide, so it can accommodate multiple words without obscuring parts of the user's query.

Reveal Site Content

6. Show Examples of Real Site Content

Don't just describe what lies beneath the homepage. Specifics beat abstractions, and you have good stuff. Show some of your best or most recent content.

7. Begin Link Names with the Most Important Keyword

Users scan down the page, trying to find the area that will serve their current goal. Links are the action items on a homepage, and when you start each link with a relevant word, you make it easier for scanning eyes to differentiate it from other links on the page. A common violation of this guideline is to start all links with the company name, which adds little value and impairs users' ability to quickly find what they need.

8. Offer Easy Access to Recent Homepage Features

Users will often remember articles, products, or promotions that were featured prominently on the homepage, but they won't know how to find them once you move the features inside the site. To help users locate key items, keep a short list of recent features on the homepage, and supplement it with a link to a permanent archive of all other homepage features.

Use Visual Design to Enhance, not Define, Interaction Design

9. Don't Over-Format Critical Content, Such as Navigation Areas

You might think that important homepage items require elaborate illustrations, boxes, and colors. However, users often dismiss graphics as ads, and focus on the parts of the homepage that look more likely to be useful.

10. Use Meaningful Graphics

Don't just decorate the page with stock art. Images are powerful communicators when they show items of interest to users, but will backfire if they seem frivolous or irrelevant. For example, it's almost always best to show photos of real people actually connected to the topic, rather than pictures of models.

When to Work on Usability

Usability plays a role in each stage of the design process. The resulting need for multiple studies is one reason I recommend making individual studies fast and cheap. Here are the main steps:

  • Before starting the new design, test the old design to identify the good parts that you should keep or emphasize, and the bad parts that give users trouble.
  • Unless you're working on an intranet, test your competitors' designs to get cheap data on a range of alternative interfaces that have similar features to your own. (If you work on an intranet, read the intranet design annuals to learn from other designs.)
  • Conduct a field study to see how users behave in their natural habitat.
  • Make paper prototypes of one or more new design ideas and test them. The less time you invest in these design ideas the better, because you'll need to change them all based on the test results.
  • Refine the design ideas that test best through multiple iterations, gradually moving from low-fidelity prototyping to high-fidelity representations that run on the computer. Test each iteration.
  • Inspect the design relative to established usability guidelines, whether from your own earlier studies or published research.
  • Once you decide on and implement the final design, test it again. Subtle usability problems always creep in during implementation.

Don't defer user testing until you have a fully implemented design. If you do, it will be impossible to fix the vast majority of the critical usability problems that the test uncovers. Many of these problems are likely to be structural, and fixing them would require major rearchitecting.
The only way to a high-quality user experience is to start user testing early in the design process and to keep testing every step of the way.

Turning a list into a navigation bar


The markup is very simple. It’s an unordered list, with each link in a separate list item:

Why use a list? Because a navigation bar, or menu, is a list of links. The best (most semantic) way of marking up a list of links is to use a list element. Using a list also has the benefit of providing structure even if CSS is disabled.
At this stage, with no CSS applied, the list will look like any old (normally bulleted) list, styled only by the browser’s defaults.
I’ve given id attributes to the ul and li elements. The id attribute for the ul element is used by the CSS rules that style the entire list. The li elements have different id values to enable the use of CSS to highlight the currently selected link. This is done by specifying an id for the body element. More on that later.


I’ll describe the CSS I’ve used to style the list in a step-by-step fashion.
First of all, I set the margins and padding of the list and list items to zero, and tell the list items to be displayed inline:

#nav {
#nav li {

This will make all the links display one after another on the same line, as if the list wasn’t there. It will also remove the list bullets, since they are only displayed when display:list-item (the default display mode for list items) is used. Some browsers are said to incorrectly display the list bullets even though display:inline has been applied to the list items. I haven’t seen this happen in any of the browsers I tested in, but if you want to make sure that no browsers display list bullets, you can add list-style-type:none to the rule for #nav.

Next, it’s time to start styling the menu tabs. I do this by adding styles to the links, not to the list items. The reason for that is that I want the entire area of each tab to be clickable. First a bit of colour to make the changes more obvious:

#nav a:link,
#nav a:visited {

Note that I’m styling the normal and visited states of the links to look the same. the next step is to add a bit of padding to the links:

#nav a:link,
#nav a:visited {
padding:20px 40px 4px 10px;

That’s a bit better. But there is a potential problem that isn’t visible here. Since the links are inline elements, their vertical padding will not add to their line height. It’s easier to see this if the ul element has a background, so I’ll add a background colour and a background image:

#nav {
background:#808259 url(nav_bg.jpg) 0 0 repeat-x;

Oops. Now the links are sticking out of the list element. To fix this, I’ve turned the links into block boxes by floating them to the left. I’ve also set their width to auto, to make them shrink to fit their content:

#nav a:link,
#nav a:visited {
padding:20px 40px 4px 10px;

Adding display:block to the CSS rule for the links would also have made them block boxes, but since a floated element automatically generates a block box, that isn’t necessary.
As you may have noticed, the background disappeared when the links were floated. That’s because floated elements are taken out of the document flow, which causes the ul element containing them to have zero height. Thus, the background is there, but it isn’t visible. To make the ul enclose the links, I’ve floated that too. I’ve also set its width to 100%, making it span the whole window (except for the padding I’ve given the body element in this example):

#nav {
background:#808259 url(nav_bg.jpg) 0 0 repeat-x;

To visually separate the links from each other, I’ve added a right border to the links. Then, to give the first link a left border as well, I’ve used a :first-child pseudo-class to apply a rule only to the link in the very first list item. I’ve also added top and bottom borders to the ul element:

#nav {
background:#808259 url(nav_bg.jpg) 0 0 repeat-x;
border:1px solid #42432d;
border-width:1px 0;
#nav a:link,
#nav a:visited {
padding:20px 40px 4px 10px;
border-right:1px solid #42432d;
#nav li:first-child a {
border-left:1px solid #42432d;

The :first-child pseudo-class is not recognised by Internet Explorer for Windows, so the first link won’t have a left border in that browser. In this case, that isn’t a major problem, so I’ve left it like that. If it’s really important to you, you’ll need to add a class to the first list item (or the link in it), and then use that to give the link a left border.

Next I’ve changed the way the link text is displayed by removing the underlining, making the text bold, specifying font size, line-height, and a different font family, making the text uppercase, and adding a little bit of drop shadow. The drop shadow is created with the text-shadow property, a CSS3 property that is currently only supported by Safari and OmniWeb:

#nav a:link,
#nav a:visited {
padding:20px 40px 4px 10px;
border-right:1px solid #42432d;
font:bold 1em/1em Arial, Helvetica, sans-serif;
text-shadow: 2px 2px 2px #555;

To give some visual feedback when the links are hovered over, I’ve given their :hover state different text and background colours:

#nav a:hover {

In the final step, I’ve added rules that will make the selected link look different than the others, to show visitors where they are on the site.

In case you haven’t seen an example of specifying an id attribute for the body element to style the “current” navigation tab differently before, that’s what the first two rules do. In the examples linked to from this article, I’ve set id of the body element to “home”, which makes the “Home” tab the current one. Changing it to “about” would make the “About” tab the current one, and so on.

I’ve also made the selected link stay the same when it’s hovered over. It can be argued that the current menu item should not be a link at all. In this case, I’ve chosen to leave the link in the markup and use CSS to remove the visual feedback on hover.

To give some visual feedback when you click on one of the links, I’ve given the :active state of the links the same styling as the selected link:

#home #nav-home a,
#about #nav-about a,
#archive #nav-archive a,
#lab #nav-lab a,
#reviews #nav-reviews a,
#contact #nav-contact a {
#home #nav-home a:hover,
#about #nav-about a:hover,
#archive #nav-archive a:hover,
#lab #nav-lab a:hover,
#reviews #nav-reviews a:hover,
#contact #nav-contact a:hover {
#nav a:active {

the finished navigation menu.

That’s it. This step-by-step tutorial makes the whole thing look more advanced than it really is. View source on the final example to see the complete set of CSS rules. By the way, with a couple of small exceptions (the left border on the first link, and the text shadow), this works in just about any browser, even Internet Explorer (version 5 or newer).

I hope you’ve been able to follow along well enough to be able to create your own navigation menu. The styling possibilities are almost endless.

What (Definition of Usability)

Usability is a quality attribute that assesses how easy user interfaces are to use. The word "usability" also refers to methods for improving ease-of-use during the design process.

Usability is defined by five quality components:

Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
Efficiency: Once users have learned the design, how quickly can they perform tasks?
Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
Satisfaction: How pleasant is it to use the design?

There are many other important quality attributes. A key one is utility, which refers to the design's functionality: Does it do what users need? Usability and utility are equally important: It matters little that something is easy if it's not what you want. It's also no good if the system can hypothetically do what you want, but you can't make it happen because the user interface is too difficult. To study a design's utility, you can use the same user research methods that improve usability.

Debugging CSS in Internet Explorer - Part 1

For web designers and developers, fixing CSS issues in Internet Explorer is a daily chore. Not too long ago I decided to document these issues and what I did to fix them. This article will be the first in a series of articles containing real world CSS problems and solutions. Although some of these problems have been talked about elsewhere, I hope this article will help designers and developers to debug CSS issues quicker and make the most of their time.

The W3C's XHTML and CSS Validators

It may seem obvious, but I've seen so many css issues resolved because of some unclosed elements or simple spelling errors. Some of the validators' feedback may seem cryptic at first but after using it over and over, you will be able to instantly pick out problems. Make sure you turn on the "show source" option in the validators so you can quickly match the problems line by line.

A Reality Check

If you're working with a test server, separate from your local machine, make sure you're working with the correct files. I've made this mistake and I've seen others make this mistake; it's always good to double check.

CSS Problem Solving

Elements are disappearing

When dealing with floated elements in Internet Explorer it is possible that some elements seem to completely disappear. This is commonly referred to as the peekaboo bug. If you apply position:relative to the vanishing element it should pop right back into place. I've also seen elements disappear in print and not screen despite using the same stylesheet in IE7.

Margins seem to be doubled

Another float issue found in Internet Explorer. Some people might be tempted to take the easier way out and deliver different CSS code to Internet Explorer, whether by hacks or comments. It's best to avoid these practices and try an alternate route. Although Internet Explorer can become clueless with margins and float, it will still understand padding. If possible, set the margins to 0 and try to compensate with padding either on the element itself (if it doesn't affect the appearance) or on a parent element.

Element with a height of 1px, but Internet Explorer increases it to 10px

Internet explorer uses the line-height of an element as a kind of unintentional min-height. So, if you try to set a div to height:1px for example (such as a decorative element) and the default line-height (probably inherited from parent elements) for that element is set to 10px, the height of that element will be forced to the line-height in Internet Explorer. To get around this, you can set line-height:0 and manually set the height.

An empty anchor tag is not clickable

It may seem unusual, but in my experience I have come across this more than once. Say you have an anchor element that you've given display:block and some dimensions with no content or background image, in order to make a clickable area, but in Internet Explorer it's not clickable. In order to keep the anchor invisible you can add a transparent 1px background-image. Suddenly, Internet Explorer understands that this is a clickable element.

An element's text is squished, causing it to flow downward

More than likely this is caused by floating an element without setting a width or by a floating sibling element's width being slightly too small where the squished element can't break out. Try setting a width on the squished element, or a larger width on the sibling element. If these methods don't work, use clear to break the element away from the floated sibling element.