Digital Web Magazine

The web professional's online magazine of choice.

Web Design 101: Positioning : Comments

By Tommy Olsson

April 16, 2007


Andy Wheeler

April 17, 2007 5:52 AM

I have been reading Tommy Olsson’s work for several years. Tommy is a well informed, articulate programmer. I look forward to the remainder of this series.

Matthew Pennell

April 17, 2007 6:05 AM

@Andy: Each article in this Web Design 101 series will be written by a different author, although we certainly hope to attract Tommy back for future articles on Digital Web!

Robert Wellock

April 17, 2007 6:53 AM

The example page Tommy wrote was supposed to be served in UTF-8 but for some queer reason they server has been set to send it as ISO 8859-1. This has of course resulted in mangled unreadable text making him look unprofessional (I suggest that problem gets sorted out by using NCR escapes if necessary). Other than that it was a good article.

Matthew Pennell

April 17, 2007 7:23 AM

Thanks for pointing that out, Robert, we’ll get right on it. :)

Dustin Diaz

April 17, 2007 8:24 AM

And by “containing block,” you mean “offset parent,” which is the way it’s referred to in the DOM. This proves that the W3C is disconnected. It seems awkward that they wouldn’t have mentioned it on the page that you paraphrased the quote from.

Also, in standards mode, the root node of a document can be found through document.documentElement.

Also, if anyone is interesting in knowing how they can get fixed positioning in IE6, you can try the following:

body { background: url(foo) fixed;

selector { position: fixed; top: 0; _position: absolute; _top: expression(eval(document.documentElement.scrollTop));

Jeff Seager

April 17, 2007 9:33 AM

This article is extremely well written and well organized for newbies, or for anyone needing a quick reference. I hope future articles maintain that high standard. I often find the comments to your articles very useful too (like the one above from Dustin Diaz). Thanks!


April 17, 2007 10:57 AM

Great article. I have lots of experience positioning and floating but am looking for some tips on layout with dynamically generated content (inserted from a database). I have so much trouble because I don’t have full control of the size of my divs. Unfortunately, the solution I keep falling back on is tables. Any tips would be great.


April 17, 2007 11:51 AM

Very entertaining! Now write an article about related bugs.

BTW, the font used in the article is small and pale, I just had to disable css for this site.


April 17, 2007 3:53 PM

Excellent article. However, why do most CSS advocates present false cases against table based layout?!
In terms of Tommy’s arguments:
old-school – this is irrelevant. Much of the html used today is just as old.
deprecated – incorrect. Tables are fully supported across more browsers than CSS.
Bad for accessibility – Based on most web stats, more users are still using older browsers that DONT support CSS than PDA’s or Mobiles that don’t support tables.

Don’t get the wrong idea. CSS is definitely the way of the future and an excellent development. But tables are not dead (and never will be) and are the best solution in a small (and becoming smaller) number of cases.

Mike Barlund

April 17, 2007 9:11 PM

This was a very useful article for me. It was right about my level – I use positioning some times but I feel like I’m hacking my way through things because I didn’t fully grasp the rule – until now. Thanks! Now I have a lot of re-coding I want to do…


April 17, 2007 9:39 PM

I really liked this article. Very entertaining and readable! Helped clarify some things for me, and I hope to see more articles by Mr. Olsson.

Tommy Olsson

April 17, 2007 10:15 PM

@Dustin: the term ‘offset parent’ could be inherited from the ‘DOM 0’: the pre-standard, browser specific DOM implementations.

One of the links at the end of the article describes a way to fake fixed positioning in IE, which is similar to the one you used.

@Matt: layout tables are bad in so many ways. The mixing of content and presentation is only one of them. – old-school: it is relevant, because there are more modern ways that are far better (CSS) – deprecated: tables are not deprecated, and I have never claimed that they are, but layout tables are deprecated. They’ve never been officially sanctioned by W3C. – accessibility: not a huge problem, but layout tables nested 9 levels deep (I’ve seen such pages) are a real pain for a screen reader user. The problems with layout tables have more to do with usability than accessibility, though. A single table with no rowspans or colspans will usually linearise OK, even in non-table browsers like Lynx. The point is that they are unnecessary, unless a big part of your visitors are still using Netscape 3. :)

Robert Wellock

April 18, 2007 4:10 AM

I am glad you have now fixed the example document. Though in the main article I suggest the [at] @ characters within the CODE samples need sweeping away.

Nested tables are pure evil.

Patrick Fitzgerald

April 18, 2007 7:05 AM

Excellent article, I’m looking forward to the article on floats. I have received a lot of kudos for the following page that interactively shows the different positioning options:

I never knew about the stacking context for z-index until I ran into some problems recently. My problems appeared only in IE – Firefox appears to use a global z-index so you can make “next or c to slide in between a and b”.

Jon Cram

April 18, 2007 1:10 PM

Excellently good way of explaining positioning. I’ve read some decent recent books that explain positioning, which by no means give bad explanations, but I find that everyone has their own slight different perspective on it and the angle used in this article really works.

Concerning position:fixed in IE, the suggestion from Dustin is by far the best of a few possible methods and I use it frequently.

The posted method lacks just a tiny bit – it only works in IE6 and not IE 5.x as document.documentElement doesn’t exist (I don’t recall now whether it is specifically null or just ‘blank’).

For IE 5.x (I’ve only tested with 5.5), use:

top: expression(eval(document.body.scrollTop));

I use conditional comments to separate the IE-specific expressions and keep them in separate style sheets, but the underscore hack is just as good.

If you’re feeling brave, you can combine both IE6 and 5.5 methods into one line:

top: expression(eval(document.documentElement ? document.documentElement.scrollTop : document.body.scrollTop));

That’s just off the top of my head and should work if document.documentElement equates to false in IE 5.5. I’ve never tried testing this due to having separate stylesheets to hold fixes for each ‘common’ IE version, but if someone wants to give it a shot please shout loudly if it works.

Carlos Eduardo

April 18, 2007 1:52 PM

Very good article.
I like the way you explained these CSS different ways of positioning.

Great to newbies, but still useful for more advanced users to know more about the basics!

William Yang

April 18, 2007 10:45 PM

I completely agree that CSS for page layout is the way to go but I also have to agree with Matt that CSS still does not address some of the nuances of visual design that tables have been successful at for a long time. One prime example of how CSS layout doesn’t quite hold up is if you reduce the width of your browser to 300px or less in width while viewing the example posted in this article. You will notice the following layout issues:

1. The word ‘Positioning’ in the page header “CSS Positioning” wraps over the left nav.
2. The right sidebar overlaps the main body text and also makes the main body column really narrow causing the main body to only support one word of text per line.

The main reason for this is that the CSS does not hold its width. I have seen many examples of static and liquid CSS layout options and they all suffer from these effects. Maybe there are solutions to these issues but thus far, I have only been able to rely on table code to ensure that my page grid does not break under minimum monitor resolution settings.

Jon Cram

April 19, 2007 1:27 AM

@William: CSS-based layouts can handle anything a table-based layout can and with a number of benefits that are impossible due to the nature of a table, for example you can’t take a table cell out of the flow of the table and position it elsewhere in the layout. Width management is perfectly possible with CSS, but often needs to be explicitly specified whereas with tables this may not be needed.

Table cells are pretty much fixed in place with respect to the table and the rest of the document. This rigid structure has obvious benefits, but these are also drawbacks.

Take a three column layout with left-hand navigation, centre content and right-hand sidebar. A three columned table will give you this, but what if you want to shift the rendering order and have the navigation on the right and sidebar on the left? With a table you’d have to move the content to the ‘correct’ location in the markup. With CSS, just change a few properties.

I’m not just trying to do a bit of table bashing here, and by no means wish to strike out at William for being a bit table-supportive, but merely wish to reiterate the point that table based layouts are fixed, unscalable and, in the long term, much more expensive to maintain. CSS can offer the same layout control, you just need to know how, when and why to do it. The concept that ‘tables do it just fine and are easier’ is a common misnomer with those not familiar with building CSS-based layouts and does take a bit of a leap of faith to really get rid of tables but the effort is definitely worth it.

CSS can handle the same visual layout and rigidity as that offered by a table, but as has been pointed out, this is not often successfully achieved.

With respect to the example document, it’s purpose is to demonstrate all the four positioning values. Making the layout ‘perfect’ was probably beyond the scope of the article and would probably take an unjustifiably long time – i.e. the layout breaks not because CSS can’t handle it, but because no-one bothered to make the CSS handle it as this was not the point.

To summarise: CSS can handle anything a table can (for layout purposes, that is) and is more flexible and scalable. The fact that this often seems to not be the case is either due to incorrect CSS usage or poor CSS handling by browsers.

With respect to the latter, things are getting better with every new release of IE and with respect to the former, you merely need to practice, learn things over again from the CSS perspective and then keep on learning. CSS Mastery covers some great layout techniques and is worth its weight in pixels.

Tommy Olsson

April 19, 2007 6:49 AM

@William Yang: You could easily create a CSS layout that adapts to the window size just like a table does. A 300px width is probably too narrow for a multi-column layout, though. With CSS and floats you can make one column drop below the other if the window becomes too narrow. That’s something you can’t achieve with tables.


April 23, 2007 8:44 PM

I write a french Blog about Webdesign and programming. Shall I translate this amazing article into French ?


April 24, 2007 2:17 PM


You’re just being silly. We all know exactly what Tommy meant, don’t we? When used for layout, tables are indeed all of the above, but I’m not going to take the trouble to argue each individual point.

I never understand why there are those who come out of the woodwork to argue what is already assumed, digested, and moved past. We know about the small and smaller cases. Even fewer of those are related to layout. If a newb comes along and reads that and understands it as written, it will save him or her a heck of a lot of trouble.

Let’s not make it harder than it is, shall we?


April 25, 2007 3:51 AM

Thanks for this great article. Sometimes i will still secretly use tables though :P

Thierry Koblentz

May 7, 2007 10:54 AM

This is a fine article, but I’m not sure it is going to help people create robust CSS layouts.
FWIW, the only time I use “position” in my layouts is to “fix” IE (stacking context). IMO, using “float” and “margin” is a safer way to go. For example:
One HTML markup, many layouts.

Regarding the “fixed” hack for IE (suggested by Dustin): I believe html {background:url(foo)} works as well, with the advantage of allowing authors to use a background image on body.

Tommy Olsson

May 8, 2007 9:33 AM

@Thierry: I’m not advocating absolute positioning for whole layouts, really. I prefer to use floats for that, too. But I was asked to write about positioning, not floats, and you can do some layouts with positioning.

John Macpherson

May 17, 2007 4:52 AM

Excellent article, very well written and explained. Cleared up a few issues i had doubt about. Thanks.


May 22, 2007 6:15 PM

I would expect this article to be accompanied by diagrams of the concepts (inline, not as a separate page). Otherwise, I’d say quite a bit of the readers won’t comprehend.

Sorry, comments are closed.

Media Temple

via Ad Packs