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.

The main push for elimination of tables is the use of tables to create predictable margins around the text. The padding attribute on the "body" tag in the stylesheet fixes this nicely.

But they really haven't come up with a "nice" way to create columns of text and photos without using tables. Every time I try to use the "div" tag to create columns, it tangles into a single vertical column if the browser is open in a small window.

CSS 3 will offer columns.

The fact that CSS3 will have it is another incompatibility between new browsers and old.

We need to remember the following when assuming that everyone can upgrade to the latest technology:

1. Many conmputer users don't have the money to upgrade operating systems every three years as Microsift demands.

2. Many computer users don't have the money to replace the computer every few years, to keep up with Microsoft enlarging the Windows operating system.

3. People in some foreign countries have to make do with older operating systems, because of one or more of the following:
- The US technology export embargo to some countries
- Their networks can't handle the latest material
- There is limited availability of hardware in that country
- Their government restricts what can be sent over the networks

4. Many people have legacy systems having nothing to do with the Internet that they have to keep running, often for scientific research purposes. The change to Windows has deprecated some types of time-dependent precision process control (Microsoft designed the system timing with business users in mind). This is why some users still have Lynx, Gopenr, or other text-only browsers. They need to be able to collect data with their legacy systems and transfer it over the net.

It's not so much incompatibility as unimplemented previously, or implemented to a lesser standard previously. It's not correct to expect older browsers to display things exactly as new browsers do; or even to work within the latest standards. For that; every browser would have to have been implemented with the ability to update and rewrite itself silently. A far better idea would be versioning...! wait a minute; that's what happens.

Development is certainly a good thing; unfortunately it's difficult to sit and wait for development to stop and be ready (i.e. everyone having it) because that's not really the nature of development.

Looking at a W3C page (first result in google for 'CSS3 date') shows it was scheduled to be conceptually complete by the end of 2000. Seven years later; 'modern' browsers are only just implementing the complete CSS2 spec. I'd say thats less an incompatiblity and more about what the impetus of new browser's development has been: I'd rather see well tested and correct CSS2 implementation than badly implemented CSS2 & 3. As it is, neither is really the case on any browser, but at least there are clear standards to aim for these days.

It would be bad, if using new standards made all pages inoperable under older standards. But that's very rarely the case. All HTML and CSS specs are quite backwards compatible (but certainly not pre-emptivly forwards compatible).

Anyone who releases information specifically for text only browsers makes an effort to release code compatible with those browsers. That's not impossible. People who use those browsers know what they're doing, and know the shortcomings of their browser. 'Hey, I'm going to go look for the nicest visual website designs; and I'm going to use Lynx'. You just wouldn't hear that.

It's not that tabled sites don't use CSS. The distinction is that layout and style tends to be shared between CSS and tables in a tabled design. Tableless design uses tables when appropriate, but Structure and Style (layout) is separated. Structure in the HTML, Style in the style sheet.

Clarifying Further:

As an e-Commerce, designer, there's an SEO reason to use tableless design, but it seems to be little understood factor that isn't being picked up in the posts to this thread.

The ability to write semantically correct markup in the 'logical' contextual order that presents keyword strings within an readable hierarchy is what makes tableless design useful for e-Commerce. It's why we rewrote osCommerce into a tableless CSS osCommerce application for our clients.

The fact that we can put important content and navigation directly in line with TITLE, H1, H2 and P up at the top of the source code is what makes the page seem more relevant for that particular keyword string:


We can go further and create a DIV with an ID of header, then have that above information contained with "display:none" in the CSS with a background image consisting of the logo. Viola! Google sees keyword-rich text and readers see your $2,000 beautiful, graphical logo.

Right under that, another H2 followed by the main page content. Following that, the keyword-rich text links that lead to pages with matching TITLE tags. After that, all the rest of the less important content, 'about us' page links, etc.

That order in an e-commerce site pops the site up past tabled designs, all else (such as link popularity) being equal.

Why? Because, to Google and other readers, the hierarchy is clear. In a tabled design, the logical order of the content and its importance is not always so clear and rarely linear.

But, before we can let the whole debate between tables verses tableless, here's a couple of reality checks:

http://joeclark.org/book/sashay/seri...Chapter10.html
http://css-discuss.incutio.com/?page=TablesVsDivs

Sites that present dynamic lists of anything (forums are a good example) will almost always use a table to present something, somewhere. Tables line up their rows and columns, tables are easily visually interpretable, tables can easily be populated from a database. Using a combination of HTML DIVs and SPANs and CSS to emulate a tabular layout for the data is always going to be "150% hacky. "

Question1: What do you mean by 150%hacky?
Question2: Dynamic based websites always use tables is that what you say in here? I'm a table user ever since I use DIV recently and still figuring out the ways how can I implement make my layout-designs look good in every browser!



My friends discourage me in using tables

I have some more insight now:

Using div tags for columns works fine if the divs are on the top level (i.e. inside only the body tag). But just try to make a set of columns with div tags inside some other structure, and you get a grade-A mess.

So I came up with a simple set of rules to use to decide whether to use a table to create layout, or to use divs and styles:

- Use styles to create the page margins that were formerly created by tables.

- Use tables to present tabular data.

- If the columns are supposed to be inside any tag other than body or div, use table. The div method won't render correctly inside many other tags (especially the li tag).

- If you have to cruft up a kludge to make your layout work with one method, use the other method.

- Decide what should happen if the browser window is too narrow for your content to fit. If you can tolerate any of the following, use div tags. If not, use tables:

-- The column format falls apart into a single vertical column.

-- Items end up in the next row when they don't fit.

-- Images cover each other, or cover text.

-- Text renders on top of images.