The graphics
The image below shows the desired end result. The pie is built up out of serveral layers of graphics on top of each other. Much like layers in PhotoShop.

The plum colour is the bottom layer, on top of it apple, then grape, lime, banana, avocado, blueberry, cherry and chocolate. (anti-clockwise). The top layer covers all the other segments. It's a white square with a hole in it and it has the black ring on it.

- The cover layer with it's cut out. The hole contains a half opaque, radial gradient, which causes the soft shadows on the segments underneath.
- The stacked segments.
An image was created for each percentage of that layer. This makes a total of 100 images per colour. In order to view the graph in perspective, an oblong square was created in Photoshop, of which each side was divided into 25 segments. Added up, this makes 100 segments. Now it's easy to align the gap of the shape to each crossing point along the sides of the matrix.

The markup
Each layer is in the markup represented by it's own div. To be able to generate the graph dynamically, an image will be assigned to each div by means of an inline style element. The first div is the bottom layer, the second div is the layer above it, etc. The last div has a class "pieGraph-super". This is the cover layer.
<div id="pieGraph">
<div style="background: url(pieGraph-plum-100p.png)"></div>
<div style="background: url(pieGraph-apple-087p.png)"></div>
<div style="background: url(pieGraph-grape-082p.png)"></div>
<div style="background: url(pieGraph-lime-079p.png)"></div>
<div style="background: url(pieGraph-banana-069p.png)"></div>
<div style="background: url(pieGraph-avocado-045p.png)"></div>
<div style="background: url(pieGraph-tangerine-041p.png)"></div>
<div style="background: url(pieGraph-blueberry-015p.png)"></div>
<div style="background: url(pieGraph-cherry-013p.png)"></div>
<div style="background: url(pieGraph-chocolate-006p.png)"></div>
<div></div>
</div>
The file name of each used image, such as pieGraph-plum-100p.png, consists of a colour indication and a number. The number indicates how much of the pie will be occupied by that layer. So, 100p for instance, stands for 100 percent. From now on we call this value, the 'p-value'. The p-value of the first layer (visually the bottom layer, but in the first layer mentioned in the markup) will always be set to a 100 percent. The p-value of each next layer will calculated like: p-value of previous layer, minus the desired 'real' value of that layer.
The style sheet
The dimensions of the mother div, in this case 450 pixels times 170 pixels, is the first thing we add to the style sheet. Next we indicated that the division should act as a blocklevel element.
div#pieGraph {
width: 420px;
height: 170px;
float: left;
display: block;
position: relative;
}
It's important to give the division a relative position. With this division, all the layers for the pieces of the pie will be 'stacked'. We want the layers to end up on top of each other and not underneath each other. Therefor we write: position: relative;.
The behaviour for all div elements within div#pieGraph now may be stipulated under div#pieGraph div in the CSS file. Again, the dimensions of the layer will be fixed. This value is the same for all layers. The line position: absolute means that every layer with position itself at coordinate 0:0, as apposed to the next higher element with a relative, or absolute positioning. In this case: the mother division of the graph. This way, we can make sure that all layers will be stacked upon each other, rather than be rendered underneath each other in the browser.
div#pieGraph div {
width: 420px;
height: 170px;
display: block;
position: absolute;
}
We now get the following result:

We neatly cover the layer with the top layer by simply adding <div></div>to the markup. Now the graph is finished. That is... almost.
The little 'M-problem'
The file format of choice for images of the pieces of the pie is the Portable Network Graphics format. It's support for transparancy in different grades makes it ideal for stacking all the different graphics that contain lots of diagonal lines and curves. These lines and curves would look rather jagged if the GIF-format was used instead. Besides that, the subtle shadow that's genereated by the top layer, would not have been possible at all in this way. Although PNG has been a common standard since 1996, Microsoft will only start to fully support this open format in version 7 of their popular web browser Internet Explorer. For now, we'll have to offer Internet Explorer users an alternative in the form of a GIF alternative of the graph.
Every layer now needs to be added twice to the markup:
<div style="background: url(pieGraph-plum-100p.gif)"></div>
<div style="background: url(pieGraph-plum-100p.png)"></div>
Now it's quite easy to hide All layers that contain PNG images in Internet Explorer and to hide all layers that contain a GIF image in other browsers, by means of a simple child selector hack.
div.ifMSIE {
visibility: visible;
}
html>body div.ifMSIE {
visibility: hidden;
}
.ifOther {
visibility: hidden;
}
html>body .ifOther {
visibility: visible;
}
The image below, shows the end result in both Internet Explorer 6.0 and an other grahpical browser. As you can see, the end result in Internet Explorer is not quite as stunning as in other browser, but it's still more than usable and just as clear as the render result in more modern browsers. See what the end result looks like in your browser.

- Left: The render result in Internet Explorer 6.0.
- Right: The render result in modern browsers.
Other recent articles:
-
Dealing with Labels by Cornelis G. A. Kolbach — February 1, 2009
Read more...As suggested in the article Form Follows Function and Achieving Thereof, every input element on a form should ideally have a label. Labels give more meaning to input elements and makes them accessible. This article dives into dealing with labels and input fields for postal addresses on forms.
-
Form follows function and achieving thereof by Cornelis G. A. Kolbach — February 1, 2009
Read more...Forms can be dreadfully tricky to style and structure properly. Several articles that are out there focus on best practises for building forms using HTML en CSS. This article focusses in a non technical fashion on the use of meaningful nomenclature and how form semantics relate to elements that current markup standards have to offer. It may help you recognise structural patterns and to compose forms properly.
-
Gregorian date input diversity by Cornelis G. A. Kolbach — February 1, 2009
One of the most common interaction patterns one can find on forms is the date input group. They appear in all shapes and sizes in various applications and sign up forms on websites. Certain forms of appearance seem to be more popular in certain geographical areas than other. But other than that it is hard to find any pattern or rationale why one website has chosen for model X while the other has chosen model Y. The suspicion would rise that the date input method is often dictated by the way the backend would 'like' it. This is a situation which neither we, as interaction designers and consultants, nor the end user should settle for.
Read more... -
AJAX and the Old World by Cornelis G. A. Kolbach — November 19, 2006
Most of us know that HTML was designed in such a way that it would enable one to (single) click on certain underlined words in a text, that would link to another page. Initially, these hyperlinks were the only clickable items on web pages. Soon enough, besides using hyperlinks in an inline fashion, they would be grouped on pages so they would form a menu which would help people to navigate between pages that belonged to a certain group of pages. The web site was born.
Today, complex layout methods have made it possible to borrow from interaction patterns of desktop applications, including drop down menu bars, expanding trees and tabs. It's this exact inevitable shift of desktop application design patterns to the page metaphor that has more than often led to confusion amongst both web designers and end users. In this era of AJAX and RIAs, the possibilities for user interface designers have become infinite. Hence the question arises: Have all of these developments actually led to an improved user experience?
Read more...