Try any of those footers from the Google search above in IE8 or Opera (some don't work in IE7 either). Load the page then grab the bottom of the window (not the side or corner of the window) and drag it up or down and you will see that the footer usually sticks in the wrong place, messing up the display.

Now try it on my old original sticky footer version (circa 2003 which pre-dates all those above) and you will see that my version is working in all browsers including IE8.

Before we get into details I should first explain what a sticky footer is.

What is a Sticky Footer

A sticky footer is one that sits at the bottom of the viewport when there is not enough content in the page to push the footer down. If there is a lot of content then the footer sits at the bottom of the document and will be below the fold as usual. Why this is desirable is because on short content pages you won't have a footer right at the top of the screen looking very strange indeed as shown from Figure 1 below.

Figure 1 - normal footer close to content.

Figure 2 - Sticky footer at bottom of viewport.

Note that a "fixed positioned" footer is not the same thing as a sticky footer as a fixed positioned footer is one that sits at the bottom of the viewport at all times and never moves. Don't get confused between the two.

Overview

Before we get into the nitty gritty detail I will briefly explain the concept in getting a sticky footer to work.

The first thing we need to do is create a 100% high container which is achieved by setting the html and body elements to 100% height and then creating a container that is a minimum of 100% high. The footer is then placed after this container which means it will be invisible as it will be below the fold of the page but by the magic of negative margins we can bring it back into view at the bottom of the viewport.

Of course this means that the sticky footer must be a fixed height (pixels or ems will do) so that we know how to accommodate it with the exact negative margins that bring it into view. This also means that our footer is now overlapping content on the page so we will also need to protect this content with either padding on an inner element, or some other similar approach as you will see when we get into specifics later.

That's basically all there is to it except that we have to squash a few bugs on the way to make it work everywhere.

When to use a Sticky Footer

Sticky footers are best suited for fixed width sites with small copyright messages and horizontal menu links that keep the footer at a relatively small size. The technique will work with a large height footer but the chances are that if you have a very large footer it will always reach the bottom anyway by the time you've got your header and content in place. It will also work with percentage width footers but remember that if the content in the footer is squeezed into making the footer higher than it was then the negative margin routine won't match any more and the layout will be misaligned slightly.

Creating The Footer

Now it's time to get your hands dirty with the code and I will break the method down in easy steps.

1) Create a 100% high wrapper to fill the viewport.

This is accomplished by removing the default margin and padding from the html and body elements and then setting a height of 100% so that our wrapper element can base its height on this. We then use min-height:100% on our page wrapper and not height:100% because our container would never grow otherwise but we will still need to address IE6 as it doesn't understand min-height at all. (If we didn't apply a height to html and body then our container would collapse to auto height and would not stretch to the bottom. The margins from html and body must also be removed because they would increase the height and thus ruin the effect as we want an exact 100% height only.)

As mentioned previously IE6 doesn't understand min-height therefore we provide a rule for IE6 only (using the star selector hack to target IE6 and under only) using the height property instead. We can do this because IE6 treats height as a minimum and will always expand an element to accommodate its content when overflow is set to visible (which is the default). We must also hide this height rule from other browsers because this would limit them to only an initial 100% and therefore the element would never expand with content.

Don't be tempted to use the !important hack to provide the height property to IE6 because the routine causes IE7 to be buggy with 100% height and won't resize the footer when the viewport is resized vertically.
i.e. Do not do this:

PLAIN TEXT

CSS:

1. #outer{
2.     min-height:100%;
3.     height:auto!important;
4.     height:100%;
5. }

Do not do this either:

PLAIN TEXT

CSS:

1. #outer{
2.     min-height:100%;
3.     height:100%;
4. }
5. html>body #outer{height:auto}

Both the above will fail in IE7 due to an obscure bug and should not be used in this routine.

The result of this code is that we now have a container that stretches to 100% height of the viewport quite nicely but the footer is sitting under this element and therefore under the fold of the page.

To bring the footer into view we first have to give it an appropriated height and then using a negative margin we drag it back into view. The negative margin can be applied in either of the following three methods.

1) A negative top margin on the footer itself
2) A negative bottom margin on the main wrapper
3) A negative top margin on the main wrapper

The first two methods are basically the same and just cause the footer to slip up over the bottom of the wrapper by the appropriate amount. Remember that the negative margins must match exactly the height of the footer. As a consequence of pulling the footer upwards it may indeed overwrite any content that was above it so you would also need to add some padding to the content above. The padding couldn't be added to the main wrapper because that means it would be too high and therefore the padding must be added to an inner element instead or just added to the element above the footer.

The third method mentioned above uses a slightly different tack in that the whole wrapper is moved upwards with a negative margin thus allowing the footer to fall into view at the bottom of the viewport but with the consequence that our wrapper now starts above the top of the viewport and out of sight. We therefore need to soak up this space on an inner element much the same as we did with the other two methods.

In 99% of cases you will most likely have a header element at the top of your page and you can use this element to soak up the extra space. My preferred method is to use a solid border on top of the header to do this because unlike padding it would not interfere with any absolutely positioned children should there be any.

Assuming our footer is 40px high the code to accomplish this is shown below:

The top border soaks up the space that is above the viewport and allows content to start in the viewport where it should be. This is exactly what we wanted and is quite a slick way to do this as we no longer need to worry about any overlap of the footer.

To make it easier to follow here is the code so far:

With the code shown we are very close to have a working footer and indeed the code above will work in IE6/7 and Firefox with no problems. Try out the above and see for yourself.

The problem with the above code is that it doesn't work properly in IE8 or in Opera. If, as already mentioned, you move the window by grabbing the bottom of the viewport (not the side or the corner) then the footer becomes mis-positioned or doesn't move at all.

This is the behavior seen in all other sticky footers but it doesn't occur in my original demo. The clue to why my old demo is still working will provide us with a neat solution that can be wrapped into this specific footer routine.

Back in 2003 not many browsers understood min-height and to accommodate these browsers I used a min-height hack which was basically a 100% high float that was 1px (or even 0px) wide. This held the browser open to the initial 100% height quite nicely without affecting much else as long as we took clear of clearing issues. The 100% height float triggered opera into resizing the page correctly once the viewport was moved and caused the footer to be drawn into the correct position.

Today (and thanks to the quiz I set at sitepoint) we can apply that 100% float using the pseudo element ":before" and negate the need for any extra html mark up at all.

The code above places a 100% high float that has no width as the first element on the page. This enables Opera to resize nicely and keep the footer where it should be. To negate any possible clearing issues on normal page content we use a negative top margin to pull the float high above the viewport (32767px is Opera's limit so don't use any more than this). Even with the negative margin applied Opera still continues to resize the page nicely.

IE8

The last browser to address is IE8 as it won't play ball with this method although it does understand the pseudo element :before, it doesn't apply the 100% height to it as required. Therefore we need another fix and again the answer is quite simple and logical and we supply IE8 with height:100% but declare the element as display:table. This will enable the element to be 100% high initially but also to expand if content dictates which is exactly the way that tables work.

As IE8 is the only one that needs this rule we will use conditional comments to supply this rule to it. In order to tidy up we can also remove the IE6 hack we added earlier and put it in the conditional comments as shown below.

If you are not familiar with the first line of the conditional comments shown above then in English it basically says "If less than or equal to IE6 or If greater than or equal to IE8 then use the code below".

As IE6 doesn't understand display:table then it is simply ignored by IE6 and it gets the height:100% rule only. IE8 on the other hand understands both and gets both just as it needed. This saves using two sets of conditional comments and keeps the page nice and tidy.

Here is the full code with comments to make it easier to understand or you can view source from the Full live version.
Full Code

Just in case you are thinking that there is too much code overhead in this if we look at the html needed you will see that there aren't really any extra elements (apart from assuming that you have a header in the page.) The minimum html is as follows.

I don't think you can get neater than that!

Although I have shown the example in a fixed-width format you can use it in a percentage or fluid width page as long as you take care with the footer dimensions and don't let the footer height increase with content. To enable text-resizing you could size the footer and negative margins using ems but that would assume you were basing them on the same font-size, etc.

Things to watch out for

Remember to take into account the effect of collapsing margins on the first and last elements in the wrapper because these may have an impact on the position of the parent or the position of the footer.

I also often see problems where authors have tried to make space at the top and bottom of the page by simply moving the wrapper down the page. The result of this is it moves the whole 100% down the page and ruins the effect. Everything has to happen in the 100% high wrapper and if you want space at the top then you would need to reduce the space at the bottom or be creative in other ways.

Here are just a few various examples.
Main Version
Example 1
Example 2
Example 3
Example 4

I hope you have enjoyed this article and if you have any questions then post away and I'll try my best to answer them.

One of the values for the display property is inline-block and although it has been around for quite a while now browsers have been slow on the uptake which is a shame because it's just the sort of thing that can be very useful. In this article we will investigate ways to implement display:inline-block in a number of browsers.

If you are unfamiliar with inline-block then its use is defined as follows: "an inline-block makes the element generate a block box that’s laid out as if it were an inline box".

What this means is that a "block level box" can retain most of its block level capabilities but in an inline environment. This would allow you to align a number of boxes on the same line all with their own width and height much in the same way as floating the elements but having the benefit of allowing inline rules to be applied to them unlike floats.

For example, three or four inline-block elements could be aligned horizontally and centered by using the text-align:center property on the parent. This would automatically center the elements within the available width. We could also apply the vertical-align:property to align their top or bottom edges with each other.

Perhaps it's best to start with the finished example so you can see what we are talking about. The result is also shown in the screenshot below.

Figure 1

As you can see in the above we have achieved three (apparently) block elements all aligned nicely in the same row. The elements are perfectly centred and they all have their bottom borders aligned with each other. Imagine trying to do this with floats.

The truth is you could not do this automatically with floats at all as you could never align the bottom borders unless you were using fixed heights and then could calculate the margins for each. It is also very difficult to center floats also. With very little code we have achieved this effect so now we will get down to specific details.

How's This Done

For Firefox 3, Opera and Safari we simply use the display:inline-block property value and that's all there is to it. The vertical-alignment is taken care of by using the vertical-align property which applies to inline elements only which includes inline-block elements (not forgetting table cells of course).

The centering is handled in the same way that we would center text with text-align:center.

Using the above properties our basic code to center and align three elements is as follows.
CSS

HTML

Browser Support

At present the support for inline-block has just been added to Firefox 3 while Opera and Safari already support it.

So far so good but what about IE and Firefox2 I hear you shout!

For Firefox 2 (and earlier) we can use a Vendor Specific Extension and use the proprietary display:-moz-inline-box; (not -moz-inline-block as you may have expected although that property does exist).

-moz-inline-box will allow Firefox 2 (and some older versions) to have a similar functionality as if they were using display:inline-block. Although I often tell you to avoid proprietary code there are times when nothing else will do but it's a risk you take and a choice you must make for yourself. Remember that proprietary extensions don't follow the standard exactly and may differ to the real CSS property and of course they won't validate.

So, armed with our new code let's add it to our existing CSS and see what happens.

If you test the result in Firefox 2 you will get a display as shown in Figure 2 below.

Figure 2

Unfortunately although the red blocks are aligned as expected the text inside is flowing out of the containers. It seems that this extension has a few bugs so we will need to add an extra wrapper around our blocks and apply another width to hold everything in place.

The rules are changed from targeting the p element and applied to a surrounding div instead which allows us to set a width on the p element to contain the text within the block. In most cases you would have a wrapper like this anyway so it's no real problem.

The change in code is as follows:
CSS:

HTML:

With the changes in place our layout now clicks back into position and looks exactly as Figure 1 with all blocks aligned as expected.

Now with Firefox 2 looking pretty good we turn our attention to our favorite browser: Internet Explorer.

IE has partial support for inline-block but only supports it on elements that are naturally inline by default. What a waste as it's usually block elements you want to change!

It is actually the case that inline elements just need "haslayout" and they will automatically behave as inline-block elements. They don't in fact need display:inline-block at all and applying the proprietary zoom:1.0 will have the same effect as specifying inline-block. The "haslayout" trigger must be one that applies to inline elements as width and height won't do as they are only "haslayout" triggers for block elements.

Therefore to make an anchor display as inline-block you only need to specify this.

Or

So we have established that we can make inline elements obey inline-block rules but what do we do for block level elements?

It turns out that you can also make block level elements behave as if they are inline-block elements by setting a property that will ensure the element is in "haslayout" mode but it must be a valid "haslayout" trigger for an inline element because we will be setting the element to inline in the final stage of the technique. Once "haslayout is set then in a separate rule we apply display:inline to complete the effect. Note that the order of the rules is important and the display:inline must follow the original "haslayout" trigger but in a separate rule.

As mentioned above the "haslayout" trigger has to be one of the properties that cause "haslayout" to be true for inline elements therefore we can't use the block level triggers because the element is now inline which is why height and width will not be "haslayout" triggers for our new inline element as mentioned above.

So what properties apply to inline elements that will trigger "haslayout"?

The MSDN site has a list of available properties and we will need to choose from this list.

We could use display:inline-block because that is a "haslayout" trigger for inline elements but if we apply it in the same rule then that will over-rule the display:inline setting and all we get is an element with "haslayout" but not inline block. We could use zoom:1.0 in the same rule and that would create an inline-block element.

e.g.

However as zoom is proprietary (non-valid) IE only code we can use another method which utilizes display:inline-block. The only caveat is that as mentioned before we must specify it in a separate rule so we don't cancel out the display:inline effect.

I should re-iterate that all we are doing here is creating an inline element with "haslayout". The display:inline-block is only incidental in that it is applying "haslayout" and as shown above the zoom property could be used to similar effect.

Whew - did you get all that?

Armed with the knowledge above we can re-vamp our code to cater for IE7 and under. IE8 supports display:inline-block properly (as far as I can tell) so we will use conditional comments to pass the values to only IE7 and under.

The revised code is as follows.
CSS

IE Html:

Main Html:

That just about wraps it up and we now have blocks aligned in most browsers. Please refer to the full demo for the complete code as the CSS is all in the head (just view source).

I hope you've enjoyed this little foray into the wonderful world of IE and now you can all get back inline.

I am going to start by showing the finished product as this will help you visualize what we are going to achieve along the way. Figure 1 below shows a smaller version of the task ahead.

Figure 1

We are going to make a similar display but without using tables as in my view the information presented is not tabular and does not have a logical correspondence between rows and columns. Even if you do present a good case of why this should be in a table, please don't comment on this as we are interested in the layout techniques rather than perfect semantics (for this example). The techniques presented here can be used in other layouts that are certainly not tabular and will prove useful in many situations.

Define Your Content

The first thing we need to do is decide what elements we are going to use to style this category list. That's your first clue - we should already be thinking about using a list to do this. However, I feel that information like this is more suited to a definition list (DL) as the product name is the data term (DT) and the description underneath is the data definition (DD). (Feel free to disagree but whatever method you choose the techniques used to construct our layout will likely be the same.)

I'm using a Definition List which will allow us to semantically describe the heading and the associated text that describes the heading.

Although definitions have default styling applied, such as margins, we can simply get rid of that using one of the many reset techniques available. I am using a global reset for purposes of the demo but I suggest you look into more thorough methods.

Lets' start by thinking about what we want to achieve.

The image needs to be at the left of the layout and the text needs to be lined up nicely alongside the image but we don't want the image to wrap underneath the image as that looks a little messy in a list like this.
e.g. Not like this:
Figure 2

As you can see the last line of text wraps under the image rather spoiling the effect so we will look at how to overcome this problem without complicating the issue too much.

The image can be floated to the left and we can apply a right margin to push the text away at the side. So for a start we will do just that and see what our display looks like.

HTML

CSS:

If you run the above small code sample you will see a display almost exactly as that shown in Figure 2 above. The image is floated nicely to the left and the text wraps to the right side of the image except that the last line wraps under the image.

We will address that issue in a moment but it's important to mention at this stage that floats are removed from the flow and if you want them to stay inside your container you must use some sort of clearing mechanism. Otherwise the float will float out of the container and poke into the container below should content be less than the height of the image.

In our example I have added overflow:hidden to the dl container which will ensure that all floats are contained within. Overflow other than visible will cause elements to contain their floated children in most modern browsers. IE6 needs "haslayout" to be true and then it will auto clear floats also. This can be achieved by setting a dimension which we already have in place so no extra hacks are required. Overflow isn't always the most suitable clearing mechanism to use but in simple layouts it works well but you should investigate other clearing techniques also.

Additionally, note that I have placed the image inside the dt element because the product image and it's title are really the same thing.

Stopping The Text From Wrapping

Usually authors would apply a left margin to the text content to make it steer clear of the image but this is not the best solution for three main reasons:

1) Firstly your images may be supplied dynamically and be of varying widths and therefore your left margin approach would fail unless you set a width wider than all the images.

2) The second problem would be that IE6 has a "3px jog" on static content next to a float and would make the display look slightly odd. Sometimes this is barely noticeable but it can still be annoying.

3) Lastly and more importantly, if you have floated content mixed in your content description section and you try to clear them you will end up clearing all floats and the whole description drops below the float. Figure 3 shows an example of this.

Figure 3

(Example shows what happens when a float (the red box) is cleared)

Luckily there is a simple method we can turn to that cures all these problems quite easily. (As an aside this method was also exploited earlier in one of John's Articles.) If we once again use overflow other than visible on this content we can make it form a rectangular box to the side of the image and also honoring the image's margins. It's almost as if we have floated another block to the side except that we haven't.

The overflow:auto (or overflow:hidden) causes the element to form a rectangular block that will not only stay at the side of the floated image but will also contain any floated children. As another bonus It will also contain the effect of any clearing of floats in that section. Float clearing from within that overflow:auto container will be restricted to that container only and not just clear all floats above in the HTML as per usual.

The overflow method doesn't work in IE6 but fortunately forcing "haslayout" on the element concerned has exactly the same effects and with an added bonus of partially curing the "3px jog" mentioned earlier. As we don't want a dimension in this container we can use the height:1% hack supplied via the star selector hack to target IE6 and under only.

Therefore all we need to add to the CSS already shown is this:

If you run that code you will get a display similar to Figure 1 above.

The only extra element in Figure 1 is that I have placed some text to the right of the product title. I did this by placing the text in a strong element and floated it to the right. However as floats need to be in front of the content that they will wrap (except for inline content on the same first line as the float but few browsers obey this anyway so its not worth arguing about) I have moved the strong element in front of the product description as follows.

There you have it. With relatively little code we have avoided a number of bugs and behaviors and produces a nice looking layout. I mentioned earlier that our fix only partially cured the 3px jog and the eagle eyed among you will note that although there is no jog on the content it does happen to be 3px further away than other browsers. If this is an issue for you then you can always offset this with a hack that applies 3px less right margin on the image. However I don't think many people will notice so I am not bothering to apply another hack.

The finished layout can be found here and I suggest that you copy the code from the demo itself (view source) if you want to practice these techniques.

Note that position:fixed doesn't work in IE6 and under so you will need to be using another browser although we will try to accommodate IE6 with some alternate styling.

Fixed to What?

Fixed positioning varies from other positioned elements in that the element is always placed in relation to the viewport and not a local stacking context. Even if you add position:relative to a parent of the fixed element it is still placed in relation to the viewport.

This can present problems if you want to place the fixed element inside a centered layout and then place it at a certain position within that centered layout.

In order to have a positioned element inside a centered layout you can simply let it occupy its normal position in the flow and not specify any position values for top, bottom, left or right at all. This will enable the element to become fixed at that point while the rest of the content scrolls.

We'll work through some simple examples to show this in effect.

We'll start with this simple Example

Figure 1

As you can see from the example above this places the fixed element exactly at the top of our outer div and it remains there even though content will scroll. Try scrolling the page up and down and you will see that the fixed element always remains in view.

Let's see what happens if we now try and add some positioning to move it into another position.

Figure 2

The fixed element has now jumped out of the centered container and is placed 100px from the left of the viewport. It ignored the centered container's position altogether!

This is because as mentioned above fixed elements are always placed in relation to the viewport so we cannot use top, bottom left or right when we want to position within another element.

Margins to The Rescue

Fortunately we can use margins to push our fixed element around inside our centered block.

Figure 3

That pushes the element nicely into position as shown in Figure 3 above.

Although we have shown that the fixed element can in fact stay in tune with our centre element it should be noted that the fixed element won't be constrained by this parent and should content stretch the fixed element wide it would just overflow at the edges of the centred container. You would need to set a specific width if you wanted to constrain the width to match its current location.

Fixed Footer

We have now established that we can't use positioning inside our centered element so how can we place a fixed footer at the bottom of this container? A top margin can't be used this time because we don't know the height of the element and it will of course vary depending on content. If we use the position value of "bottom" then the fixed element will jump to the bottom of the viewport and not the bottom of the element we are concerned with.

In fact the answer lies once again in first using the normal rules of positioning to achieve the layout you want and then fixing the element once the layout is correct.

First of all we achieve the look we want without using fixed positioning.

One way this can be done is to absolutely position an element at the bottom of our layout and then add an inner element that is set to position:fixed. This means the element will be placed at the bottom of the layout and then it will be fixed at that exact position.

Here is the example:

As you can see in Figure 4 the element is now placed at the bottom of our layout but because #outer isn't scrolling it appears to be doing nothing different from an absolute element.

Figure 4

If we shorten the viewport to cause scrolling then we find that our fixed footer has been fixed below the viewport and is invisible as shown in Figure 5 or see for yourself in this Example 2.

Figure 5

This brings up an interesting problem when using fixed positioning in that when the element lies outside the viewport it becomes unreachable. Bear this in mind and always make sure you can reach the element in some way. This usually means making sure the fixed element is high in the viewport or is at least fixed to the viewport in some way.

We can't really use this method for our fixed footer because it serves no purpose if we can't see it. A change of tact is needed and we will need to fix the footer to the bottom of the viewport using the bottom property while not specifying left or right positions so that our element holds true to the centered layout. However we will also need to use a 100% high centered layout if we want borders to meet the footer, otherwise it may look a bit detached. (Read my explanation on 100% height in the middle paragraphs here.)

Here is the example and the resulting code is as follows.

You will note from the above code I have added some padding to the last element so that the text is not covered up by the fixed element. Otherwise the last piece of text would sit underneath the footer and not be seen. I have also added a hack so that IE6 and under just gets a position absolute footer and will still be quite functional although it won't be a fixed footer. In dynamic situations (e.g. dynamically inserted content of JavaScript content switches) IE6 can forget where the absolute footer is so you need to take care when using it in dynamic situations. (Although as an aside I have found that if you are doing a content hide and show with javaScript you just need to nudge the footer with some JavaScript also and then it remembers where it was.)

If you really want IE to join the party then the easiest way is to use an IE expression to imitate position:fixed.

Here is another example that will work in IE6.

The expression is as follows.

Be aware that expressions only work when javascript is enabled. You can read more about expressions here and if you are also unfamiliar with conditional comments you can also read up on them here.

There is a CSS way of imitating position fixed in IE6 without using expressions or Javascript but it takes a lot of effort and is rather a risky process. If you want to take a look then I have some examples below but I will not explain them today (and they are mainly experimental and not something I would advocate using). However they are quite interesting.

Example1
Example 2
Example 3
Example 4

I hope that your CSS is now well and truly fixed!

This is a very large photo I took of a mountain near Choquequirao, Peru. Figure 1 shows it set as a normal background image without playing with CSS's background-position or anything else and only a rather boring corner of it (not that the whole image is that exciting either) is visible:

Figure 1

Figure 2 shows the same thing, except that the image has been centred using background-position:center:

Figure 2

It's even more boring! Now, with CSS we can still improve this a bit, by using the img element instead of a background image. Yes, this is not as beautifully semantic, but for the purposes of this example will do:

By setting the width and height of #bg and the image to 100%, we can fill the viewport up with the image, but of course the aspect ratio of the image will not be maintained and the stretchiness can look horrible, particularly if the browser window is resized.

Time for some JavaScript, then. The first thing to do is to make sure the image has actually loaded before we try to resize it. I've decided on the following approach:

The key thing here is that we first set an onload event listener on bgimg (the image we're resizing) which will fire when the image has finished loading. However, it will only fire if the src attribute is set, so we do that in the following line (it doesn't matter that it's the same src, fortunately).

The last three lines fire resizeBg when the browser window is resized and cater for decent browsers and IE. Here is resizeBg:

The first two lines obtain the width and height of the viewport. There is a small caveat here: For document.documentElement.clientWidth to work (since IE does not support self.innerX), IE must not be in quirks mode, i.e. the page must have a valid doctype. Not much of a caveat, really, since your pages should have valid doctypes anyway.

Following that, we just employ some simple mathematics. The first if block will set any image to the same width as the viewport. It also works out the new height for the image so that the aspect ratio is preserved.

The next if-else block is important. If the first block's calculations means that the new image's height is smaller than the viewport, we need to make it a bit bigger. This means setting the width to bigger than the viewport, so to preserve the aspect ratio, we centre it by shifting it left by half the difference.

If the height of the new image is bigger, then we need to centre it vertically, which is what the else if bit does.

Now, as shown in Figure 3, we can get a nicely-fitting centred image as the background!

Figure 3

See the finished example page (which Figure 3 links to too) and the accompanying JavaScript file. The JavaScript file includes code to run the resizing function when the DOM has loaded, using Dean Edwards' script, so the init function will look a little different to the one on this page.

Before anyone says anything, yes, the script could be made truly nice and unobtrusive by creating the HTML elements for the background image with JavaScript as well, but that is not the focus of this post, so it can be left as an exercise for the reader!

Update (29/01/09): I've updated the code to make the script work in IE6. Please note there are also changes to the CSS (in the finished example HTML file).

CSS Full Length Graphical Borders on Fluid Layout

It's quite easy to use graphical side borders on fixed width elements as you can simply repeat an appropriate sized image down the y-axis of the container and draw both edges at the same time. However, it is often not well understood how to achieve this effect with an element that has a fluid width especially in a 100% high environment.

We will first learn how to apply an image to both sides of a normal content height (but fluid width) container and then later on explore the possibilities of using this for a 100% (viewport high) container.

Normal Height Layout

Let's start with a simple example that has graphical borders on both sides of a fluid layout.

The technique is to repeat the left border down the left side of the first wrapper and then repeat the right border down the right side of an inner wrapper. You must be careful not to overwrite the first image when you overlay the second image so any background colours would need to be on the first element and not the nested element.

CSS:

The side image is 20px wide so the elements are nested allowing for a 20px gap using margins to keep the content away from the borders. We could have done the same thing with padding and saved ourselves an extra div.

The only thing to note in both the above snippets is the "haslayout" fix for IE. If you are not familiar with "haslayout" then I have a good explanation here.

Figure 1 shows the result of the above code.

Figure 1

If you have a little imagination you can improve the look -- here is another example as shown in Figure 2.

Figure 2

All that was needed was to change the image slightly and give the background a colour that merges in with the image.

The simple change above gives the layout a nice torn look down each side.

100% Height Borders

So far we have established that it is easy to place a repeating graphic on each side of a normal height layout, but what about 100% high layouts where the layout stretches from the top of the viewport to the bottom of the viewport?

This is more complicated because 100% height is a tricky subject at the best of times. In effect you can only ever have one 100% high element to play with and therefore with a fluid width element you can't tile both edges of the element in one go with a background image.

100% Height Explained

I suppose I should explain why you cannot have more than one 100% high element!

In order to achieve an initial 100% high container the html and body elements are first set to 100% height. This allows us to use the main-container on the page and to give it min-height:100%. We use min-height because we want a minimum of 100% height but we also want the height to expand should content exceed the viewport height. If we had used height:100% for the main container then the container would never expand past the viewport and content would just spill out. Therefore we use min-height:100% to get our initial 100% height.

However, because we must use min-height on the main container we cannot nest another element inside that container and use min-height again.

Why Not?

The reason is that a percentage height of an element must be based on the parent's height. If the parent is defined as height:auto (the default) then the child has no height to base its measurements on and the height collapses to auto (for both height and min-height) which is effectively content height. This is an impossible conundrum and the reason is that in most cases you can only ever work with one 100% high container and that must be the first container on the page.

I should point out that IE6 and under do not understand min-height but treat height as a minimum anyway so that is the reason you will see the IE hacks for this. In some cases IE6 will allow you to nest successive 100% high elements but other browsers will not so it's best avoided.

Now with the 100% height issue explained we can set about creating our 100% high borders. Let's start with the basic page.

Here is a live page using the above code. Simple stuff so far with the 100% height routine as mentioned earlier. Now we need a method of painting both edges with our repeating graphics. We can't nest any inner elements because they will only be content height and will look bad.

Therefore we are going to use a technique I devised for making equal columns and will apply it to make our borders. You should read the article for the full details but briefly the idea goes like this...

An absolute element is placed using top and bottom properties at the same time to hold it in tune with the outer parent. The outer parent has position:relative applied and this keeps the inner absolute element relative to itself at all times. By specifying top and bottom properties at the same time the absolute element will keep its top and bottom in place with the top and bottom of the parent always creating a 100% high element.

Unfortunately IE6 and under don't understand it when you use top and bottom together so instead for IE6 and under only we place the absolute element at the bottom of the element and give it a height that will be bigger than we ever need. It doesn't matter that the height is too big because it will simply disappear through the top of the viewport without any ill-effects.

In fact, for other browsers we don't need to use top and bottom properties at the same time. We can simply give the element a top position and then specify 100%:height. Unlike static elements, absolute elements will keep track of an auto height container.

Time for a demonstration.

The css we add to the snippet above is as follows.

The html is simple also:

The two extra divs that we are utilizing for the borders are shoved to the bottom of the current stacking context and kept nicely out of the way. This method is so simple and the extra mark-up is minimal as only one extra div than the normal height method.

Adding Transparent Shadows

A lot of sites like to have their main page bordered down the side with a transparent shadow effect. In order to do this properly transparent pngs need to be used so that the body background isn't rubbed out and can still be seen below the shadow. This is especially important if the body background has a gradient effect or has fixed images that need to be visible under the shadow.

Unfortunately IE6 (and older) don't understand how to use transparent pngs and you lose any opacity with horrible effect. Fortunately we can use the proprietary alpha image loader filter to provide IE6 and 5.5 with some sort of fix. As the filter is a Microsoft extension it's best to feed it to only IE6/5.5 (preferably via Conditional comments). For ease I have used the star selector hack to target IE6 and 5.5. I am ignoring IE5.0 as it doesn't understand the filter but you may wish to supply alternative non-transparent images to IE5 only using conditional comments.

For all other browsers we can simply use the code as shown above and instead of the border images we will use transparent pngs for the borders. For IE5.5/6 we need to add the filter which will make the relevant code look like this.

The image gets supplied to IE6 using the star selector hack but an important point to note is that you must remove the original image because it would conflict with the filter image and ruin the effect. That is the reason for the "background:none" in the IE hack.

Note also that the sizingMethod attribute is set to scale so that the image is scaled to the full height of the element it sits in. This filter is not a substitute for the background property and has limited capabilities. Read more about it in the Ultimate CSS Reference.

Here is a live example with the changes recommended (view source for the full code).

Figure 3

If you want the main wrapper to have a background colour then you need to move the edges outside of the wrapper so that the transparency isn't affected. This can easily be done by adjusting the left and right positions of the absolute elements.

Here is another live example with the background color added and the edges moved outside the main background (view source for the full code).

Figure 4

That about wraps it up for today and I'm sure you can come up with some better examples than me. Hope you find it useful.

I know that probably doesn't quite make sense but what I mean is that quite often you know how things work but it's how they are applied that can make all the difference. This is the beauty with CSS where you can always be surprised at the different ways the same layout can be achieved. This happened to me the other week when I noticed a different way that a site had been centered using simple techniques already known to us all. Indeed, many of you may already have used this method but it seems to have escaped my attention until now.

The Old Way

One of the first things I learned to do in CSS was how to horizontally and vertically center a fixed width and height element. This could be an image for a splash page (god forbid) or a small centered site that some designers love to do. Originally this was accomplished with absolutely positioning an element 50% from the top and 50% from the left of the viewport. This of course only places the top left corner of the element at the center of the viewport and you then need to drag the element back into a central position with a negative margin equal to half the height and half the width of the element.

Let's take a look at the old way of doing this and note what the problems are.

A live version can be found here and the result as shown in the Figure 1 below.

Figure 1

I have added a background image to the body just to make the page look nice so the only part we are really interested in here is the gray centered portion. (As an aside you should note that to get the background image centered in the viewport you need to set html,body to be 100% high.)

As you can see the result is what we wanted and the element is perfectly centered both horizontally and vertically. This is achieved as already mentioned by putting the top left corner of the element at 50% from the top and 50% from the left. Then using a negative top margin and a negative left margin the element is pulled into a central position using half the elements' height and half the elements' width for the appropriate negative margins.

Although at first glance this seems to work well, there are some severe downsides to using this method and they can be seen by closing the browser window both horizontally and vertically. As the window gets smaller than the element's size the element starts sliding out of view at both the top of the window and the left side of the window. The areas that have slid outside the window are now in fact unreachable even by using the scrollbars on the window. This would mean that users with small screen sizes could not access the content at all.

Figure 2 shows what has happened to the one line of text from our example when the window is closed smaller.

Figure 2

The text is half missing at the top and has also disappeared to the left. If we closed the window further the text would disappear completely. In order to try and address these issues a min-height and min-width has been added to the body, but as you can see this has had no effect at all and the element still lies outside the viewport.

Revised Method

In light of these problems another similar version of this centering technique can be used where the element is still placed absolutely from the top but this time the horizontal centering is achieved using auto margins. This also eliminates the element from sliding off the left of the window.

Here is the revised code.

A live version can be found here.

This has the desired effect horizontally but still leaves the top disappearing upwards when the height of the window is made smaller as shown in Figure 3.

Figure 3

The Fix

Now to get over this problem (and to get to the point of this post) I have previously used more complicated methods but there is a simpler, more robust solution involving a float instead of the absolute element.

The first element on the page is a float that is set at 50% of the height of the page. Then we drag the float upward by half the height of the element we want centered.

Here are the changes needed:

Here is the link to a live version so you can see for yourself.

Figure 4

The important part is that we use a float of 100% width and then also remember to add clear:both to the following element as some browsers will get confused otherwise. If we did not use "float" then the element would still be centred but it would also disappear through the top of the screen unlike the floated method.

Why This Works

This throws up an interesting behavior concerning floats and it's good to understand what's going on here exactly. Why is it that when we use a static element (or an absolute element as in the first example) that the content disappears through the top of the viewport but doesn't do this with a float?

The nature of floats is that they are removed from the flow (although you can regain control by using "clear" on following elements). The content following a float is displaced to make room for the float (usually by the browser increasing the top margin on the static content to clear the float). If the float were not there at all then the content would occupy its normal position in the page. Therefore when using a negative top margin on a float, the float will travel outside the confines of any containing block because as we stated previously a float is basically removed from the flow. However if we drag the float far enough outside the containing block so that none of it exists inside, then any following content cannot continue to follow the float upwards but resides inside its containing block allowing the float to float way.

This is in fact what happens in our example as the float is dragged upwards away from the body and the following content has to remain inside the containing block formed by the body element. This may be a little hard to understand straight away but can be seen in a simple demo as follows.

The code above sets a static element at the top of the page followed by a float and then followed by more static content which produces the result seen in figure 5 below and in a live example here.

Figure 5

Nothing special there and all working as expected.

If we next add a 100px negative top margin to the float we get the result as shown in Figure 6.

Figure 6

Still everything as expected but what happens if we increase the negative top margin to 200px?

Figure 7 shows the result once again.

Figure 7

As you can see the float has moved away from the following content but the content that was below the float stays at the top of its own containing block (i.e. beneath the green block). This is exactly what happens when we drag the float outside the viewport in our main example.

However if we were to simply remove the float property from our red div then both the red div and the content below would be dragged up over the green element.

Figure 8

With a static element the flow of the page under the element with the negative margin is changed and all the content is dragged upwards accordingly.

I hope you have enjoyed this little tip (even if you already knew about it) and it shows that there is always something new to learn for all of us. Refer to the original example for the full source code as it is all in the head to be grabbed easily.

If you want to look at some more advanced centering techniques then I have a few other methods documented here. Have Fun!

Why Should I Validate?

I don’t know the answer “why you should validate” but I certainly know why I validate.

In a recent article on Search-This a poster commented that it was unnecessary to validate HTML and CSS and served little benefit so I thought it would be wise to explain why I always validate and why it is good for me. You can then make up your own minds whether you should validate or not.

The usual response of the uninformed is that "validation is not necessary" and while I agree that validation for the sake of validation is not necessary, it most certainly is necessary if you want to keep tight control of your work and limit the chances that something will go wrong.

Probably as many as 5 out of 10 calls for help that I receive are things that could have been solved by simply running CSS and HTML through the W3C validation service.

Take the following code for example which is a snippet from a recent call for help.

If you run the above code in Firefox you will see that all the styles for #outer fail to show up. Although the CSS is just a few lines the error is quite hard to spot straight away. Now imagine if the file was hundreds of lines long; the task of finding the problem would be even harder. As soon as you see that something is wrong the first step should be to run the CSS and HTML through the validator to see what it has to say about the code.

Running the above CSS through the CSS Validator flags an error straight away.

Sorry! We found the following errors (1)
URI : file://localhost/TextArea
5 Parse error - Unrecognized }

Straight away we can see that there is a stray closing bracket causing #outer to become unrecognized and the styles to not get applied. For finding errors like this and other errors such as mis-typed properties and values there is no quicker way to spot the exact error than simply running the code through the validator before you start to blame the browser.

More advanced coders can get away with validating their work less frequently during development but for beginners it is a must and should be done frequently. In this way, silly errors are avoided and the beginner is also alerted to the fact that they may be using an incorrect property or value.

It's basically like using a spell checker which will fix your words but doesn't mean that you can write anything sensible. You still need common sense and to have some idea of what you are doing.

When you've looked through as many sites as I have (over 20,000) you know that validation is necessary to weed out all the silly errors and typos that creep even into the best code.

I never validate my pages just so that I can put a sticker on the page (which I don't do) but I do validate my page to see what errors are on the page and then make a decision to live with them or not. If the errors are missing div tags or typos then I will fix them.

If the error is because I am using a non-standard proprietary CSS then I can live with that as long as I understand the implications. Validating your page regularly will keep the code clean of silly errors and allow you to get on quickly with the job in hand.

It's basically like using a spell checker which will fix your words but doesn't mean that you can write anything sensible. You still need common sense and to have some idea of what you are doing.

Validation for the sake of validation is a different matter but validation for the sake of weeding out silly errors and typos is a must and I strongly recommend doing this to save at least some hair-pulling.

Of course just having valid code does not mean that the page will be rendered correctly but it does at least allow you to look in the correct place for the error when something is not right. Too many times I see the browser blamed for something which was an error in the author's code and not the browser's fault at all. The fact that one browser may display the code OK and another may not does not mean that either browser is wrong but just they may have different procedures for when errors are encountered. Using the correct code in the first place would have avoided the issue at stage one.

However, I will agree that the validators may appear a little unfriendly at first but understanding the validator is another skill that needs to be learned (along with all the other things a web developer has to cope with). It's worth the effort and will pay dividends in the long run.

"Why should I validate" is still therefore a valid question with an easy answer.

"It will save you time and effort and also shows you care about your work".

As an example I thought I'd document a few problems that crop up time and time again with absolute positioned elements in our favorite browser - yes, IE6, I'm talking about you again!

Removed From The Flow

Absolute elements are removed from the flow and have no affect on surrounding content. Conversely surrounding content should not be able to affect absolute elements either. That's not quite true as a positioned element will create a stacking context for further positioned elements but that's as far as any effect will go. (We often set position:relative on a parent so that the absolutely positioned child can be placed in respect of that parent and not the viewport.)

In effect the absolute element should not care what else goes on around it and is oblivious to anything except its own start position. IE, however, has a few peculiar issues with this in the simplest of layouts and we will document a few of the most common and thought-provoking problems you will encounter on a day to day basis.

The following examples are a little contrived in order to show the effects at the simplest level and could be done by other methods but that's not the point of the exercise.

The Disappearing Margin Trick

The following example creates an absolute element at the top of the page which is 100px high. The following element is static but has a margin top of 100px to move it below the absolute element by 10px (remembering that absolute elements are removed from the flow so that the margin is taken from the top of the container and not the absolute element).

If you run this code in Firefox you will see something like the screenshot in Figure 1.

Figure 1

The code couldn't be simpler as it's basically two lines of code but let's see what IE makes of it.

Figure 2

As you can see the yellow block which follows the absolute element has completely disappeared in both IE6 and IE7.

Where has it gone?

Although I said the yellow block has disappeared that's not quite true. If we reduce the width of the absolute element we can see the yellow block skulking underneath the red block.

With the absolute element's width reduced, the yellow block can be seen at the edge shown in Figure 3.

Figure 3

So what can we deduce from this?

It would seem that the top margin on static content is ignored in IE when it follows immediately after an absolutely placed element in the HTML.

For my next trick....

We know the issue is not a "haslayout" issue because the element already has a "layout" due to the width we gave it. Let's try floating the following content instead and see if that fixes the problem for us.

All we have done is to add float:left to the static content and the result is shown in Figure 4.

Figure 4

Well things are looking much better in IE7!

IE6 is also showing the yellow block in the correct position but unfortunately IE6 has now hidden the red absolutely positioned block!

Obviously floating fixes IE7 but leaves IE6 still broken so it's not a solution we can use.

What else can we try?

Let's first remove the float we just added so that we are back to the original code and try something else. The following solution is one that I have tried and tested and probably posted 2 or 3 times a week in the forums. We won't change the CSS at all but instead address the HTML. If we move the absolutely placed element to the end of the current stacking context then all these problems disappear.

All we have done is to move the div that has a class of "abs" to the end of the current stacking context (i.e. to the end of #outer). The result of that simple change can be seen in Figure 5 below.

Figure 5

Both IE7 and IE6 now display the elements correctly. It's a pain that the HTML has to be changed but I have found that this is the only reliable way to squash this rather annoying bug.

And there's more....

The strangeness doesn't stop there I'm afraid. If we use the new revised HTML but change our yellow block to be floated we observe another strange behavior in IE6 and under.

The result of adding float makes the absolutely placed red block disappear altogether as shown in Figure 6 below.

Figure 6

We fixed our original problem by changing the order of the HTML which made everything work fine but now that we've added a float to the element following the absolute element we find that the absolute element has disappeared again. Damn!

Obviously we can't change the HTML around again because we already know that it won't work so what could be a solution this time?

This leads to a solution that I haven't seen documented before (except by me) and the logic of the solution is nonsense which is why it probably hasn't been noted before. In order to make the absolute element re-appear we add clear:both to the absolute element!

Of course this makes no sense because absolute elements are removed from the flow and therefore should not be affected by floats. Clear floats in our current example would seem to have no bearing in any shape or form. However, believe it or not by simply adding clear:both to the absolute element it miraculously re-appears.

The HTML is still as follows:

Figure 7 shows that finally all elements are present and correct in IE6.

Figure 7

As I said at the start of the article the examples are a little contrived but that was in order to show the full effect of these strange bugs in the simplest of situations. Now that you know what they are and how they occur you will be able to fix them easily when it happens to you. The things to look out for are disappearing absolute elements or disappearing and misplaced content next to absolute elements or when floats follow absolute elements in the HTML. The full-proof solution is to move the HTML for the absolute element to the end of the current stacking context and then to add clear:both to it.

IE makes CSS so much fun -- if things were to just work the first time, where would be the fun in that?

No, I haven't gone mad yet - it's just been a long day and I couldn't think of a suitable tag line so I just burst into song. As you may have guessed I've got a bad case of the scrolls today but the doctor says I'll be fine.

Let's get to the point before you run for the door. This week we will look at how to create an element where the inner content is larger than the parent. We'll also look at how by using the overflow property on the parent we can arrange for scrollbars to appear so that the inner content can be viewed.

This may seem like a very simple task. However, there's more to this than may be anticipated so bear with me and I think we can all learn something along the way. As usual let's start by viewing the finished result so that you have a good idea of what we are going to achieve. Here is a screenshot of the finished result.

Figure 1

Overflow

Most of you probably know how to do this already, but what makes the demo slightly more interesting is that the width of the inner element is undefined and therefore can accommodate any number of images that may, for example, be drawn from a database. Although at first sight you may think that this will be easy to accomplish, the truth of the matter is that if you don't specify a width for the inner element then the inner elements will just wrap at the end of the line as per normal and no scrollbar will appear even if we have set overflow to auto.

The usual way to make a container produce scrollbars when the inner content is greater than the parent is to specify overflow:auto or overflow:scroll. This usually means that both elements should have widths defined otherwise there will be nothing to trigger an overflow. (The value "auto" means apply scrollbars when necessary and the value "scroll" means stick them on the element now so that we can see them right away.)

In our example we will define a width for the outer but we want the inner elements to be width auto so that we can have as many images as required because as stated above they may be coming from our database and we just don't know how wide our inner container needs to be.

Let's start at the beginning and work our way through this one step at a time.

Draw the box and place some images inside.

The first thing we need is a box to hold our images and then we'll drop our images inside the box. As images are inline elements they should line up horizontally quite nicely. To keep things semantic we will use a list to hold all the images, but since a list is display:block by default we will set it to display:inline instead and that will allow the images to line up horizontally as we wanted.

So to start with we have set a width on our outer container (.wrap) and set the overflow to auto. That should allow scrollbars to appear when the inner content exceeds the dimensions of the parent. (I have used the same image in the demo because I was lazy but of course you would use different images, although for this demo you should keep the thumbnails the same size to make it look nice.)

If we run the above code we come across the first problem which is that as soon as the image meets the edge of the container it wraps to another line. This is shown in Figure 2 below.

Figure 2

To make all the images stay on the same horizontal line we could set a width for the parent UL, but this only works if you know how many images you'll have. We want to be more fluid (dynamic) and have it work with an unknown amount of images. A simple solution for the demo so far would be to use the white-space property and set it to a value of nowrap which will hold the inline elements all on one line without wrapping as the value suggests.

We add it to .wrap as shown below:

The result of this change gets us closer to what we are looking for as shown in Firefox 2.0 in Figure 3 below:

Figure 3

However if we look in IE we see that we get a horrible vertical scrollbar which we don't want.

Figure 4

This spoils the effect slightly so we are going to use some CSS3 (which was previously proprietary IE only code) and hide the vertical scrollbar. We will use conditional comments to apply this style for IE only so as not to upset anyone else.

We use overflow-y:hidden to remove the vertical scrollbar. Of course this means that we will have to make sure there is always enough vertical room for our content or it will stay hidden when it does go below the fold.

That cures IE and we now get the result as seen in Figure 3 for both Firefox and IE (and other browsers).

Captions

So far in a few simple lines of CSS and HTML we have managed to create a fluid width gallery that can hold as many images as needed and they can be scrolled left and right all along the same horizontal line. However, most times when you have this type of effect you will also want to have an image caption under the image as well. Therefore let's add a caption under the image and see what happens.

I have just inserted a break after the image so that the caption is underneath the image. This immediately has the effect of destroying the layout as seen in Figure 5 below.

Figure 5

Of course you knew this was going to happen didn't you?

The break we inserted obviously creates a new line so the text starts on the line below and then appears to refer to the wrong image as the next image in line lines up alongside the text. We need some way to have the image and the text treated as one block and for each block to still remain horizontal. "Ahaa" I hear you say, "we can simply float the blocks".

If we add the following CSS to our stylesheet we can have the image and the text float nicely across the screen.

Although this works well we seem to be back at square one because the floats will not honor the white-space:nowrap as that only applies to inline elements and the floats simply wrap at the end of each line and we lose our horizontal scrollbar.

Figure 6

We could address this by setting a width on the UL and then everything would be fine.

Figure 7

But we don't want to set a width on the UL because that won't allow for a variable number of images to be used so we need another approach.

The first method I am going to show is one that we have used before and involves using display:inline-block. As Firefox 2.0 doesn't understand display:inline-block we are going to use display:-moz-inline-box which is a Vendor Specific Extension for gecko browsers and performs much the same as display:inline-block for our purposes.

Although I generally don't like using these extensions there is no avoiding the fact that they can be useful at times. Therefore you must always weigh the risks yourself when using proprietary code.

I should also mention at this point that IE doesn't understand display:inline-block when used on block elements but there is a fix also for IE which is effectively setting "haslayout" to be true while also setting the element to display:inline. We do this strangely enough by using firstly display:inline-block (which is a haslayout trigger) and then setting the element to display:inline in the next rule. (Read the full explanation in this previous article as to how this works.)

Here is the extra code needed for Firefox, Opera Safari etc.

And here follows the IE fix which we'll place in the conditional comments along with the scrollbar fix from earlier.

If you refer to Figure 7 above you will see that the images have underlines underneath them because they are anchors. We want the underline underneath the text but not under the images. We can cure this simply by setting the image to display:block and the underline will only appear at the bottom under the text. At the same time we should also avoid the horrible blue border around images that browsers put on linked images by default.

As I don't like using multiple breaks in the HTML because they are hard to control I am going to wrap the text in a span instead -- we can then keep complete control from the stylesheet. To set the text on a new line we set the span to display:block and then align the text to the center as follows.

The result of all the above changes can be seen in the following demo. Just view source for the full code.

Rollover

You may notice that the demo shows a rollover effect -- this is accomplished with a few lines of CSS as follows:

We create a background image of the correct size that is placed in the anchor and then on hover we simply set the image's visibility property to the value "hidden" and that allows the anchors background to show through. The visibility:visible style is an IE6 fix as it needs a little helping hand to effect the change on the image. Obviously if all your images were coming from a database then you wouldn't want to do a background rollover like this as it would be far too complicated and would not be worthwhile.

Take Two

As mentioned earlier there is another way of getting this horizontal effect and instead of using display:-moz-inline-box we can use display:table and display:table-cell which is valid CSS and not a Vendor Specific Extension. IE7 and under will still need the old method though as they don't understand display:table (but IE8 will be able to as it has been added into IE8).

The change in code is as follows:

The ul is set to display:table and the list items are set to display:table-cell which gives the horizontal effect we need. IE would then need an extra style in the conditional comments as we have removed the "haslayout" trigger which was display:inline-block.

Just to show it does work here's the Live version. So as you can see we have two ways of doing the same thing; this is usual for CSS as there is always another way of doing something.

Fade Away

If you refer to the original finished version that I showed right at the start you will see that I have added a couple of elements to tidy it all up. Look closely at the right and left edges of the box and you can see that the image fades away before it gets clipped at the edges of the container. This is accomplished by adding a transparent PNG that fades from 0 -100% opacity at each end of the container.

I'll quickly explain how to do this for those of you that are interested.

Firstly make your PNG images in your paint package and set the opacity to fade from 0 -100%. You will need 2 images because the image on the left side will fade from right to left and the image on the right side will fade from left to right. I made the images 80px wide and high enough to provide a fade for the image and the text below.

In order to place these images at each end we will need to create another wrapper for the scrollbox and set it to position:relative -- this will allow us to easily place the PNG fade images over each end of the scrollbox.

Here is the relevant CSS and HTML only:

The faded sections are now positioned correctly at each end and as the images are scrolled they pass under the faded PNG and then fade out gradually. IE6 doesn't understand PNG transparency so we will have to use the alpha image loader filter (more proprietary CSS) and apply a fix for IE6 only (IE5 doesn't know how to use the filter but IE5.5. does).

Here is the nasty hack for IE.

I have just given conditional comments to all IE versions less than IE7 (I don't care about IE5 not working with it). When using the alpha image loader filter you must be sure to cancel out any background properties as they are not compatible with the filter. You should know that the filter is not a substitute for the background property and has no methods for positioning or repeating images. It can only use special attributes which are "image", "scale" and "crop".

The "image" attribute should be used when images are displayed at image size within the element. The "scale" attribute will scale the image to the size of the element it sits in. "Crop" will crop the image to the element's size. I will not go in to more detail here on its use but you can find out more here in this CSS Reference.

Referring to the demo, you can see that I have added one final touch and that is to add a fixed message under the scrolling images but still apparently inside the scrollable box. In fact the message isn't really inside the box I have just placed it there absolutely from outside of the box and therefore it appears to be fixed.

Caught by a bug.

This worked very well until I uploaded it to write this article!!!

Viewing the page in Firefox 2 while online showed the following error on first page load.

Figure 8

In Firefox only the second image was dropping to a new line on first visiting the page. If the page was visited a second time or refresh was clicked then the page loaded perfectly. This proved a difficult bug to fix as nothing logical seemed to work.

The only times I have seen this before in Firefox is when images (or dynamic content) are used and the images don't have their width and height attributes in the HTML. However this was not the case in this demo and I needed to find another answer (and I needed it now or I've just wasted a day writing this).

In the end I found a solution although it makes little logical sense to me. The solution was to set the main parent of the page to have position:relative added but also to have a background color set. The fix only works when both are set together.

Now the page works well on every visit and there is no dropping of the content. I can't give you an answer as to why this should fix it other than that it triggers a slightly different rendering algorithm and to tell you the truth I don't really care as long as it's working now.

The final result is here and you should view source for the full code rather than grabbing all the snippets I've posted above.

Here is a screenshot of the completed layout again.
Figure 9

That about wraps it up for this article and I hope you have enjoyed the journey. Although I said this was basic stuff we have covered a lot of concepts and I hope most of you will find at least something interesting in the above. Of course the next step would be to provide a main image to be viewed from your gallery but there are plenty of "Light box" scripts (or similar) available that can do that for you.

Until next time just keep scrollin', scrollin', scrollin'.......

Therefore I am taking this opportunity today to plug it a little as I am quite proud of the result as it took a lot of research and hard work. I believe Tommy and I make a good team because of Tommy's extensive technical knowledge and astute understanding of the finer details of the specs (something that often goes above my head), and my practical knowledge on a day to day basis with how CSS works in the real world.

Who is the book for?

The book is mainly a reference book -- it's the sort of book you should keep close to your computer so you can look things up easily when you need to know exactly how something should work and what problems you may expect when using it. There are compatibility tables for the most common browsers and the book is formatted in an easy to use fashion; oh, and it looks great also.

Most competent CSS designers will already know how the most common properties work but I can guarantee that you will find something useful in the book no matter what your level. It is not a tutorial book and it is not aimed at beginners, nor is it a "how to" book but should be used as a reference and an aid to a deeper understanding of CSS. If you have a working knowledge of CSS then you will possibly get more out of this book initially but beginners should also keep a copy handy that they can grow into.

Advanced CSSers will already know many of the concepts and perhaps also understand how to decipher the W3C CSS specifications better than others, but I can tell you that even though I wrote half the book I find myself referring to the book itself rather than the W3C specs to check up on the finer details when my memory fails me (it happens to all of us as we get older).

Many bugs and browser peculiarities are mentioned but it is not an exhaustive list of every known bug as that would make it unwieldy and was not the real purpose of the book.

I learned quite a few things during my research for the book and even things I thought I knew inside out would often surprise me when looking at the finer detail of how they work. For example, it is often stated that floats must come first in the HTML to allow the content that follows to wrap around the float. This is not 100% true for all preceding content but only for preceding block level content.

If a float has an immediately preceding line box then the specs say that User Agents should keep the float on the same line as the line-box as long as there is enough room to fit. This might be better explained with an example.

As you can see from the code above there is some preceding text on the same line before the float. According to the specs the float should float to the right but still stay on the same line as the preceding line-box. If we run the code in the latest versions of Opera and Firefox you will see that Opera in fact will render this correctly but Firefox gets it wrong.

Figure 1

As you can see in Figure 1 above Opera displays the float on the same line as the preceding text correctly. Firefox gets it wrong, as would IE (Safari will also render this correctly).

Assuming all browsers rendered this correctly this would then allow us to apply mark up as follows:

The result is seen in Figure 2 below.
Figure 2

To achieve the same effect that Opera is showing we would have to re-arrange the HTML for other browsers so that the float comes before the inline content as follows.

Figure 3
The result is seen in Figure 3 below.

Although it's only a small change it really shouldn't have been necessary if the User Agents followed the specs correctly. Also the above HTML makes less semantic sense with the words left and right being juxtaposed. There are of course other ways to have done this and the first word could have been floated left instead so its not a great issue but is still interesting to note and understand.

I hope that this has whetted your appetite and should you wish to check it out, why not visit the online reference where you can contribute and make this a growing resource for CSS.

If you are unsure of what I mean then take a look at this tooltip example.

CSS ToolTip

As you can see from the example above as soon as you rollover the anchor link a nice little tooltip box appears. I'm sure many of you know how this is done already but we'll just explain the basics a little before we move on to some more interesting examples.

The technique works by targeting a nested element that is held inside the anchor and then using absolute positioning on that element to move it somewhere else. In order to have a consistent effect we create a local stacking context on the anchor by adding position:relative to it. This means that the nested absolute element will now be placed in relation to that anchor and not the viewport (should there be no other positioned parents).

The first thing we need to do is to create the HTML that will be used for this demonstration.

In the above snippet we have nested a span element inside an anchor element and it will provide the text for our tooltip message. In order for the text inside the span not to show, we will simply hide it until it's called for. There are a number of ways of hiding the text such as using display:none, visibility:hidden or using an off screen measurement such as position:absolute;left:-999em.

The method I am going to use (which I find the most reliable) is to use visibility:hidden to hide the text. You may think that display:none would be better but IE can be a little buggy at times with this and the visibility method is more stable. The difference between display:none and visibility:hidden is that display:none will collapse the space that the element occupied to nothing; as though the element didn't exist at all.

Visibility, on the other hand, just makes the element visible or invisible but still preserves the space that the element occupies. This won't be a problem in our tooltip demo because the element is absolutely positioned anyway and therefore takes up no space in the flow of the document.

The CSS we need for his short demo is as follows:

First, we set the anchor to position:relative, as already mentioned, and this ensures the tooltip is placed in relation to wherever the anchor is at that time.

The next step is to place the span absolutely at the position we require and to hide it. The code for that is pretty straight forward and is self-explanatory.

Finally, the clever bit: when the anchor is hovered we change the visibility of the span to visible. We do this by addressing the span while the anchor is in the hover state and using a descendant selector to target the span. Although IE6 only understands the :hover pseudo class on anchor elements (a elements with an href attribute) we can still effect a change on nested inner elements by using the anchors hover state. I should also point out that you can do these hover effects on any element in other browsers except IE6 and under (even IE7 is ok) as they support :hover on nearly all elements.

The code that does all the work is simply as follows:

Couldn't be simpler could it?

IE6 Bug

However, if you try that code in IE6 and under you'll notice that the tooltip doesn't appear. This is due to a bug and IE6 (and under) won't effect a change to the span unless something is also changed on the anchor at the same time. As we don't want to change anything on the anchor, I use this "all purpose" solution and simply set the hover state of the anchor to be visibility:visible.

So our hover section now looks like this:

The visibility:visible on the anchor has no detriment to the example because it affects nothing as the anchor was already visible but it cures the bug and can be used in any situation where you need this effect. The result of the above can be seen here in this tooltip example or in Figure 1 below.

Figure 1

Two Places at the Same Time

An interesting thing to note is that the absolute element can still be the target for the href in the anchor and if we change the element to be visible at all times we can have an effect like this:

Figure 2

We have the anchor text split in two places which was done with the following code:

It's important to note that the yellow background color on the span must be explicitly defined to match the anchor's background because backgrounds are not inherited (even though most people think they are). A background will only show in a child element when that child element happens to be over the parent's background because the background's default is actually transparent. It is not inherited at all. Anyway, I digress and let's now set up a hover effect for the anchor.

When either the span or the anchor is hovered both elements will change at the same time as can be seen in Figure 3 below or this live example.

Figure 3

When hovered, both parts turn red even though they are miles apart and the space between them is not active either. You may say that looks very nice but what actual use could this present in everyday layouts?

As usual it only takes a little bit of imagination and some interesting effects can be used to enhance your boring old web page. You could have text on either side of a fixed width section and as you traverse down one side the corresponding text also highlights. Or you could have the disjointed section as a graphical element or pointer effect. There are some more advanced examples here that might be of interest.

All Change

We will look at a couple of other examples that utilize the methods above so that you can see you are really only limited by your own imagination.

First of all take a look at the final result of our first task. The screenshots below show first the normal state and then the highlighted state as an element is hovered.
Figure 4

Figure 5

Granted it's not an earth shattering demo -- the effect is that as soon as you enter the menu the whole menu changes color and each menu item is highlighted as you roll down the menu.

This example needs to be broken down in two parts because unlike the tooltip examples above each line of text is a different anchor and we need to change the background color of the ul on hover which is not possible in IE6 and under without using script. However we will get around this so don't worry.

For compliant browsers that allow hover on elements other than anchors we will use the following code:

There is nothing really clever here except that when the nav is hovered we change the whole background color of the nav and then change just the background color of the menu item.

The whole work is done here:

(I set up a current class in case you wanted one as a default.)

The CSS is straight forward and needs little explanation. We use the pseudo hover class on the ul (#nav) and then do the same for the anchor. It provides a nice subtle effect and you could substitute the background colors for images if you wished to make it more interesting.

How Can This be Done in IE?

Unfortunately as already explained we can't use the same process for IE6 and under because they only understand hover on anchor elements. Therefore we are going to use the aforementioned disjointed tooltip method to place a background over the whole navigation but we are going to do this from inside the anchor. Doesn't sound possible, does it?

The first thing we need to do is to change the HTML so that we have an extra element inside the anchor so that we have something we can re-position.

The nested span will be removed from the anchor and placed over the whole ul and will effect a change of background color to the whole ul. This is not quite as easy as it sounds. The navigation may be a fluid length as we don't want to work with fixed heights but IE6 has another bug (wouldn't you have guessed) in that an absolute element should be able to achieve 100% height of its parent. In nearly all other browsers you can set an absolute element to be 100% high of its relatively positioned parent and the absolute element will maintain pace.

IE6 (and under) doesn't obey this rule and collapses the height:100% to height auto which is effectively zero (or line-height) in our demonstration. Therefore we are going to utilize another technique of mine first seen in my equal column examples. For this method we simply place the span at the bottom of the ul and give it a height so big that it will always fill the column. We hide any overflow by using overflow:hidden on the parent. This method doesn't suffer from the "inpage links" problem that other equal column methods have suffered from.

Relative to What?

In the first tooltip example we placed position:relative on the anchor and placed the inner span in relation to the anchor. However, for this example we need to place the position:relative on the ul because we want all the spans to be positioned from the ul's position and not each individual anchor's position.

We are going to wrap the IE code in conditional comments so that only IE6 and under get it.

The revised full CSS and HTML is as follows: