Reflections on CSS Positioning

CSS positioning - some reflections

This article is not about CSS in general. The general CSS presentation features are one of the best things to happen to the web. Every page should have a stylesheet. All authors should be encouraged to use them.

This is about using "CSS positioning" to put the major few components of a page into position on the screen. In other words, to try to do things that "tables" can do, and for the past few years, have done. This is about replacing layout-tables with CSS positioning. Or not.

Here are reflections on the trials and consequences of a number of forays into designing pages that don't use layout tables for positioning the major components of the display. These forays include the following:

  1. My first involvement was to redesign the standard HTML (and associated CSS) that I use to display my photographs on the web. The target display was a centred-photograph with a border, with a few words of description below the photograph. It is hard to envisage a simpler page layout.
  2. I wanted to understand how best to develop more complex pages layouts. The messages on the web are very mixed, and mostly uncritical and/or exaggerated. I therefore focused on a specific layout, the 5-box 3-column approach used (with variations) by news services and many other organisations worldwide. I developed many such layouts using a variety of techniques, such as layout tables, tableless approaches using CSS positioning, hybrid schemes using both of these, and others such as the use of iframes, frames, objects, and mixtures of the above.
  3. I decided to develop a set of templates using tableless techniques to be used for future articles across my web sites wherever the specific characteristics of tableless layouts were appropriate. This really meant where "industrial strength" was not needed. (It had become obvious from the above that "industrial strength", meaning reliable, robust, and predictable cross-platform and cross-browser behaviour, needs layout tables).

These are some reflections and conclusions from projects that were far harder than they should have been.

Fashion models, Xian

Some forays into CSS positioning

"Simple photograph pages"

The photograph page linked to from the thumbnail in the sidebar of this page shows the result of this development.

One of my design intents was to have potential for a variety of borders round the photograph. Borders are surely presentation? So perhaps I should be able simply to include the photograph in the content, and use the CSS to put whatever border I wanted round it? I could have achieved the simple borders I really wanted by using tables. I could not find a way of doing so just by using CSS applied to basic mark-up. I ended up with HTML that said:

<div class="outer"><div class="middle"><div class="inner">
<img src="....jpg" height="..." alt="..." width="...">

In other words, in order to use CSS to present borders, I had to devise and supply sufficient mark-up, totally irrelevant to the photograph content, to give the stylesheet "handles" to work with. This need to devise and implement suitable mark-up for the presentation intention is common with CSS in general, and especially with CSS positioning. This is shown by some of the best demonstrations of the power of CSS, such as the CSS Zen Garden. If you don't put sufficient foresight & features into the HTML, you can't achieve the presentation and flexibility you want from the CSS. They are not separate. This activity was the first to demonstrate to me the lack of an adequate notation to express what I was trying to achieve. And to demonstrate the way that, with CSS positioning, mark-up and stylesheets are inextricably bound together.

This activity also made crystal clear the vital need to be aware of the deficiencies in the many browsers on the many platforms of the users who might try to look at my photographs. I have ended up with "browser hacks" in the CSS to cater for the known positioning problems of known browsers. In particular, I have a hack for IE 5, to force it to centre the photographs in spite of its (well known) deficiencies. But have I catered for all browser problems on all platforms? I haven't a clue! The only method suggested to ensure that your pages work on all browsers on all platforms is to test them on all of these.

CSS positioning is so fragile that I can publish simple material, conforming to specifications published many years ago, and not have a clue about what people "out there" can see or not see. It isn't just about whether it has the intended colour. It might not appear at the right place on the page. It might not appear at all!

A 5-box 3-column layout, with banner, leftbar, article, rightbar, and footer

"The 5-box 3-column layout"

I was sceptical about many of the claims made about CSS positioning. But I lacked the knowledge to be sure. So I chose a particular layout, the 5-box 3-column layout, and explored it in depth. Such experimentation is the only way I know of to resolve conflicts.

It is trivial to achieve this layout in a robust and reliable way with a layout table! It is done 100,000 or more times a day, because it is the basic layout of the on-line news services. There are perhaps 10,000 of these. (Google knows of 4,500, but certainly doesn't know them all). Perhaps they each publish 10 articles a day. But, realistically, surely on average they publish vastly more than this? And hardly any of them doesn't use layout tables. There is Wired of course, and c|net, and .... er .... (gosh). Perhaps between 100,000 and 1 million layout table pages are published each day, successfully. That is the true nature of the web. Now, and probably for several years.

There is an industry trying to achieve with CSS positioning what can be achieved trivially with a simple table. I transcribed the main techniques I found into my set of examples, to ensure that I understood their behaviour, and for comparison. They typically need browser hacks to get close to what layout tables can achieve, and they typically don't exceed what layout tables can achieve. They are often worse, especially in the way they "linearise" the content. They tend to require the sidebars to be before the main article.

What I find significant is that, for too many people, making CSS positioning do nearly what layout tables can do, even at greater development cost, is considered to be an "achievement". It is as though evangelists for CSS positioning are so certain of the inferiority of CSS positioning, compared with layout tables, that they feel it is a victory to have overcome this handicap. If you can do with CSS positioning what you could easily do with a layout table, you are a master, and people will talk about you!

It is sometimes claimed that using CSS positioning enables considerable changes to be made to the whole web site by changing just one CSS file. Often, this is not true. CSS positioning often relies on having the right nesting of elements in the HTML, and having the content in the right order. These are needed, for example, if "float" is used as a layout technique. Sometimes the only significant layout change that can be made with CSS alone is to swap left and right. And my experience is that most layouts don't work well both ways. I believe that is the case for my templates below.

 Users have grown accustomed to looking in certain areas on a screen to find specific items .... Internal web links were expected to be located on the upper left side of the browser window .... External web links were expected to be located on the right side or lower left side of the browser window .... The "back to home" link was expected to be located at the top-left corner and the bottom-center of the browser window .... The internal search engine was expected to be located at the top-center of the screen. 

Michael Bernard, "optimal web design", Software Usability Research Laboratory

Criteria for optimal web design (designing for usability)

It looks like it's time to ditch those table tags once and for all.... And wouldn't it be nice if life was like that? Sadly of course it's much more complicated. And much of the blame for this must be directed at CSS itself.... And while, thanks to their efforts, the main problems of how to produce workable layouts from the CSS specification have now been cracked, there are still innumerable smaller issues ready to raise their head and make the designer's life a misery. Such as: how to consistently control margins and padding to ensure alignment, how to set up a full-width footer section below columns of varying length; how to vertically centre content; how to give a coloured background to a side column that matches the height of a longer content column; and so on. These are all givens with table-based layout and should certainly have been addressed before CSS2 was allowed out of the door. 

Tom Arah

The Future of Web Layout

As powerful and useful as they are, floats can make for tricky layout tools... Because floats were not originally intended to be used for layout, some hacks may be necessary to make them behave as intended. This can involve floating elements that contain floats, "clearing" elements, or a combination of both. Looking to the future, there have been a variety of proposed enhancements to CSS that would allow an author to declare that an element should stretch to contain any floated elements within itself.... but as of this writing, support for such abilities is likely to be a long time coming. 

Eric Meyer, Complex Spiral Consulting

Containing Floats

There were really only three things we couldn't do with this redesign: properly position our partner-specific footer at the bottom of the page, use vertical alignment within divs, and achieve validation. Positioning footers is a huge Achilles heel of absolute positioning. It is ridiculous that you cannot embed three absolutely positioned columns within a master div and then position a footer below that master div. This is a well known problem of absolute positioning and there are a few workarounds, none of which are very elegant. 

Mike Davidson of

Eric Meyer's "An Interview With Mike Davidson of ESPN"

The complexity monster has reappeared, right in the center of modern Web development. Nowadays it doesn't manifest itself as an endlessly nested table, but as an endlessly complicated CSS hack. Our beloved CSS is in danger....

Especially during the first half of this year, otherwise sensible Web developers wasted enormous amounts of time in finding and improving countless CSS hacks. In my opinion these hacks are a danger to Web development, both from a psychological and from a technical point of view. Complicated CSS hacks are the modern equivalents of the frames and tables we used in wholesale lots back in the nineties....

CSS hacks are actively dangerous for your Web site. A cursory glance at the underlying "theory" (if one can call it that) will rapidly convince you that the average CSS hacker doesn't have the faintest idea what he's doing.... These hacks are inherently unsafe....

I find their behavior very unprofessional and irresponsible. It's not forward-compatible Web development. It's not backward-compatible, either. It's completely incompatible Web development, and future users of their sites will pay the price. 

Peter-Paul Koch, "Keep CSS Simple"

"Templates for future use"

When I re-engineered parts of the Child Support Analysis web site, I used simple layout tables because I judged from the above evaluation that this was sound, safe, cost-effective, future-proof engineering. But I also needed some templates for writing articles in other web sites, and I indulged myself by developing a few tableless-layouts. This page, along with the others for this topic, is an example.

This project revealed the extent to which CSS positioning is an incompetent system. This page validates as HTML 4.01 Strict. Its stylesheet validates without warnings or errors. Yet I have no idea whether it is even visible, except (I hope) to people using one of the browsers in my test-set, on Windows 2000, running on a Sony Vaio laptop, (during UK daytime)! If it is visible, I can't predict what it looks like. This isn't simply a matter of browser-incompatibilities. The language I needed to express my design intentions for these pages simple does not exist. As far as I can tell, no one ever attempted to devise a competent language for transmitting a useful abstraction of page layout decisions over the web. CSS1 and CSS2 don't come close. I'm not convinced that CSS3 will succeed either. (I am willing, indeed hopeful, to be proved wrong).

What do users want? They don't want "element X wrapped in element Y", or "element Z floated to the right". They want "External web links ... located on the right side or lower left side of the browser window", or "The internal search engine ... located at the top-center of the screen". I am willing to break some of those rules. But I want this breakage to be under my control, not to be an arbitrary consequence of a browser's inability to execute every last detail of a complex specification. If I could transmit my page layout decisions, browsers could "do their best" to get them "sort of" right. But if I can only transmit a particular implementation of my page layout decisions, any browser that can't execute every detail may go in completely the wrong direction without any clue about how to get close to what I intended. It can't "do its best", because it doesn't have a useful reference.

Obviously, when developing these templates, I hit many browser limitations. That is normal practice when attempting CSS positioning. It isn't sufficient to know the specification. In addition you have to know about the limitations of the world's significant browsers running on the world's significant platforms. (In the past, now, and in the future).

Even this isn't sufficient! I hit a problem with IE 6 that doesn't appear ever to have been documented. Perhaps I was the first to discover it. It made significant parts of the display simply disappear! It was not something that could be dismissed as "not pixel perfect"! I also grappled with the well-known "peekaboo" bug. The CSS for the page you are now reading gives this current box a style { line-height: 1.2; } to try to ensure that the text in this box doesn't come and go at random when using IE 6. How many other such bugs are "out there", making parts of my pages, and your pages, invisible to some users?

When I sketched out CSS-P designs, and tried to implement them, I had some proposals that, after lots of work, I couldn't see how to implement. Sometimes the CSS specification were totally inadequate. (I don't believe for a second that they were ever intended to support the layout of the main few elements of a page. Intelligent people would never have devised such a silly way of doing so!) Sometimes the tool (authoring & browsing) support were wrong. I put some designs on the back-burner. Perhaps I will have another look at them in a decade.

Then, as I progressed, I found myself having to make compromises because time was limited and I could only check the results on a small combination of platforms & browsers. And with CSS-P you need the coverage! One slip, on Mac IE 5.2 (say), and your design blows apart! Not by pixels - by lots! (I get screen shots emailed to me - I can't imagine how a browser could interpret the CSS I provided and end up with that result!)

So I tried to turn the compromises and restrictions into "features". Classic IBM style! I couldn't get what I want, even though with any plausible system I would be able to get it. So I tried to make it appear that what I have is what I actually tried to get. I wonder how many CSS-P layouts are compromises dressed up to look good to the uninitiated?

CSS positioning is an incompetent system

This provocative heading is intended to make a serious point, as well as being demonstrably true. It isn't enough to say things like "CSS is OK for positioning, and only the deficiencies in IE are a problem". For CSS positioning to be recommended to people, the whole system, not just the Recommendation plus some browsers, needs to work. The whole system doesn't work.

Everyone knows that CSS positioning doesn't work properly. Pretty well everyone accepts that it can't work consistently until Longhorn (the next major Microsoft operating system) has sufficiently replaced IE 5 and IE 6. Given the Longhorn will be resource-heavy, this will be years after Longhorn is released in 2005/6. Perhaps 2010?

What should a competent system have? How about:

  • Understandable specifications. (Why does it take a brilliant and knowledgeable person like Eric Meyer to interpret them for mere mortals like me and probably you?)
  • Tools for generating the material. (Authoring tools, WYSIWYG editors that can render CSS-positioned material, off-the-shelf templates, etc).
  • Tools for interpreting the material. (Browsers, both visual and non-visual, with known behaviour, on all relevant platforms).
  • Processes for answering queries and resolving conflicts. (I am not going to be critical here. I have a lot of admiration for the people who post helpful responses to newsgroups and forums. If they manage in the current deficient environment, which typically they do, I have confidence that they would manage even better if all the components were competent).
  • Processes for continually evolving and improving the system in the light of practical experience. Every good process engineer (I hope I have some of the characteristics of one!) ensures that the entire system continually improves. I personally want to be able to identify the improvement processes for every part of the process. But too much of the CSS positioning improvement process is not visible to me, and may not exist.

Would you say to someone "this motor car is great", even though you knew that, at the moment, the brakes didn't work? Surely you would either say "no, this isn't great", or you would qualify you recommendation and say "buy this when they have sorted out the brakes"? That is the nature of the CSS positioning system. Either say "no", or provide a qualified "yes, when ....".

Is this different from when tables first appeared?


When tables were introduced, there were very few browsers running on very few platforms. Layout-complexity evolved at a more controlled pace. The browsers, the web sites, and the viewing population, "grew up together". New browsers had a rich source of "test cases", the web, that they had to work with. The syntax of tables provides a relatively constrained set of combinations, and the visual format for them was well described in advance.

But CSS positioning faces the problem of having to match incredible complexity and variety of layouts. And it has to do this for a variety of browsers, on a variety of platforms, being viewed in a variety of conditions, that surely no one ever tests against. Not only does it have to work with old browsers, but it has so many more combinations that new browsers cannot be tested against the complete variety. CSS appears to have orders of magnitude more combinations than tables. Many of these are dependent on the viewport width. Most of them cannot be judged from one source, (such as the mark-up of a table), but depend on the details of the order and nesting of the mark-up as well as the order of the CSS rules.

HTML isn't a programming language. Tags are not commands. CSS isn't a programming language either. These are supposed to be declaratory. But ... the order and nesting of the HTML, combined with the complexity of the cascade, means that sometimes the only way of working out what the display will look like is to "execute" it. And consider the following:

<div id="sidebar"> the site navigation </div>
<div id="article"> the article </div>

#sidebar { width: 200px; float: left; }
#article { width: 400px; float: left; }

Where do the sidebar and the article end up? It depends on the viewport width. (Is it 600 or more pixels wide, or not?) This was just intended as a simple example to show that even having total knowledge of the HTML and the CSS is insufficient to predict what the display will be like. Yet the overall positioning of these elements is vitally important to the users. You can't easily start with the design intention and derive the mark-up and CSS. Neither can you easily start with the mark-up and CSS and derive either the design intention or the final display.

I am not aware of a set of transformations that would demonstrate that any given HTML + CSS was consistent with a stated design intention. Even if all browsers were perfect, HTML and CSS do not appear to make a formally provable system. I don't believe that CSS is "presentationally complete" in the way that major programming languages are "computationally complete". Where is the demonstration that CSS is capable, even in theory, of laying out your page as you want it?

And all the time there is the simple fact of life. If you use simple layout tables, your pages will work in virtually all of those cases! We all know it.

Was CSS (versions 1 & 2) intended to replace layout-tables?

CSS1 certainly wasn't. The Recommendation itself says: "CSS1 does not offer .... a layout language".

So was CSS2 intended to be a page layout language, and capable of replacing layout tables? I believe not - the timing was wrong, and it doesn't discuss how to handle typical page layouts. And so I would be surprised if current versions of CSS could do so, even in theory. They certainly can't in practice! There is a mention of something resembling page layout in the CSS2 Recommendation. "9.6.1 Fixed positioning .... Authors may use fixed positioning to create frame-like presentations". So this was about an alternative to frames for laying out the viewport, rather than an alternative to tables for laying out a page. And it doesn't work properly!

Even when W3C said that CSS should be used instead of layout tables, they did not show that CSS has ever been demonstrated capable of replacing layout tables. As far as I know, no one else does so either. So where has the fantasy sprung from that CSS (1 & 2) should be used instead of layout tables?

I hope that CSS3 is intended to replace the need for layout tables. But I have seen no evidence for this. I hope that XHTML 2.0 is intended to replace the need for layout tables, in conjunction with CSS3 and/or XSL. I have seen no evidence for that either.

For a whole range of tasks, table-layout is easier, and certainly more mature. And, of course, table-layout isn't even deprecated. It works well in HTML 4.01 Strict, XHTML 1.0 Strict, even XHTML 1.1. It will continue to be supported by popular general purpose user agents for a decade or two. Including those intended for accessibility and/or small screens.

The mantra "presentation should be in the CSS, not in the HTML" becomes irrelevant when you see the way that some of the CSS-positioning experts distort the HTML to give the CSS a chance! Few if any CSS positioning people could take basic marked-up content as given, add "class" and "id" attributes, then present it as desired. They have to get in and muck about at least with the linearisation order and the nesting of the document tree, and typically more than this such as adding extra controlling and wrapping <div>s.

CSS positioning distorts mark-up! It doesn't offer a clean separation.