I'll agree, IE6 is about the lowest common denominator that IE user's are gonna be visiting from. But IE6 is in no way perfect.

I really want to get some standardisation for definitions; this is what I take to be the meaning for the following terms:

- CSS Only Design = Doesn't exist
- CSS Design = Any design that makes use of cascading style sheets
- Tableless Design = Not a decision you can afford to take until a project is finished
- Design with less tables = A design approach minimizing the use of tables except in situations where they are appropriate, or more viable than any other solution.

There's no such thing as switching to CSS design for me. It doesn't register as a valid switch of anything. If a solution with floating/positioned/hierachal DIV elements to arrange a layout isn't doing what I want it to do, (on every appropriate browser), I instantly transform it into a table if a table would be appropriate. I wouldn't then dettach my CSS stylesheets in shame and clean my mind by headbutting the physical table beneath my keyboard.

I know the points where a DIV + CSS solution is probably going to fail, and avoid using DIVs + CSS in those situations. In my case; I guess that puts me off using 'correct' methods as a first choice in some cases. But, I'm lucky in that I don't work much in HTML directly; I always generate my HTML using methods that are themselves modular and styleable; so if I change the overall template for my markup, it's either a batch job for the XSL processor or a rewrite to a real-time markup transformation template and a short wait for that change to filter through a system. I know that not all designers use these methods; and I certainly understand the usefullness of CSS however pages are generated.

But my biggest issue with CSS + DIVs over TABLEs (other than standardisation of display) is:

DIVs get really bad to use when you want a page to have an arbitrary number of justified block level elements fill the width of a screen or be relative to the width of a screen. In some situations, it's ideal for objects to jump underneath each other, or be allowed to hide behind boundaries. In other situations, it breaks the intention of a conceptually strict layout.

In these situations, using table elements to arrange a layout area produces smaller and more manageable markup compared to any other solutions I've seen, or can imagine, so tables are the first choice. IF CSS supported more specific relational bindings for positioning and sizing objects relative to objects that are 'sibling' or even 'distant' in terms of a document's element hierachy (in the same way as tables do automatically), a table wouldn't be the first choice. A CSS solution would.

If creating appropriate relational bindings depended on creating a div which acted like a table, containing divs which acted like trs, containing divs that acted like tds; it would still be the better solution, because it would indeed be more modular and mutateable than a standard table. There'd be no change to the manageability of markup, and, although that arrangement effectively binds those objects into an inheritance hierachy that best suits some kind of tabular arrangement, there could be a high level of potential re-arrangements within that structure (think cell-position swapping, or mobile merges between cells).

As it is, the potential properties in current CSS specifications can only create extremely vague positioning relationships based from a direct ancestoral hierachy. Often, implicit CSS positioning relationsips have to assume fixed or parent-relative sizes for blocks which is only ok if blocks never contain too much content, or if it's ok to hide content or scroll content. AS well as the 'standard' inheratance based property cascade; CSS allows absolute and relational flexibility with positions but in some situations thats more of a hinderance than a help,

In answer to the threads title question "Why do people wish for tableless with CSS?", it's for the same reason people wish for anything conceptually perfect. For the moment at least, CSS rules cannot do everything that table rules can (and vice versa). Wishing won't change that.