Frontpage of today (IE6): Right sidebar blank at first sight, starts far down, below end of the actual page. Plus the new-topics block much wider than its heading, also seems broken from user's perspective. Typical CSS-formatting problem, usually "solved" by saying to the web-developer that he's stupid to have wider content in small area. Now it happened even at, it's unavoidable with any user-submitted content present on the site.

You still think that tableless design is better, or that today's CSS is usable for general layout of an average website? I don't think so...


Gone’s picture

IE6 is to blame here not CSS. IE has never implemented CSS correctly. This is related to IE's poor implementation of the CSS box model.

JirkaRybka’s picture

Well, with IE being used by over 90% of users, it still makes the tableless design quite useless. No need to say "blame IE!" - out site-visitors always blame the webmaster, whose site is the only one broken they came across.

Generally I think that CSS is good for formatting inside one main document (floating a text-related picture, a box with a related note etc., all done inside an article to read), but placing "another level of floats" outside the document (a sidebar) is a pain. Unless some future CSS branch introduces some "super-floats" to be placed outside basic document (like a Frameset), or at least some "expand to fit" property, it doesn't directly address the needs of any average website (with sidebars), and since I don't want to struggle with browser-dependent workarounds, I'm sticking with tables for top-level formatting as the only usable solution. (Using CSS inside the single columns then, quite safely.)

Gone’s picture

The table based design makes very large file sizes compared to style sheets even with styles sheets inside the document (instead of being attached as recommended). IE is being used by 90% of users but you can't allow MS to rule how sites are done. The common workaround is to produce an IE-only version tailored to IE's quirks but even the users are starting to realise that IE is not the only choice or the best choice ( just look at FF and Opera's recent popularity).

And that IE share is broken into about 50% IE6, 10% IE<5 and 30% IE7 (which does support CSS(while not aswell as webmasters would hope) so that means 35-40% of users are using a browser that can render at CSS at least half decently.

JirkaRybka’s picture

I quite disagree on file-sizes: I can't see how this <table><tr><td></td><td></td><td></td></tr></table> is bigger file than this <div class="leftbar"></div><div class="rightbar"></div><div class="main"></div>+leftbar { float: left; width: this; etc....} rightbar { float: right; width: that; etc. } main { margin-left: this; margin-right: that; etc. }, plus perhaps the same once more for IE only, as you suggest (not to mention waste of my time on double-debugging).

Generally, CSS might save file sizes, but that's far from being the case on Drupal, where almost everything is already-styled, so theming by CSS on large page-portions doesn't work. My theme's CSS reached over 40kB (after comments/white space removal) before I succeeded to override Drupal's CSS on every important places (usually very specific, on single elements, as cascade doesn't help where Drupal already defines single elements). Add drupal's and modules' CSS, and the CSS is one of the biggest files on page (over 50kB after Drupal's CSS pre-processing in our case). Consider also, that there's no "conditional include" on CSS, so every single Drupal page carries all the theme-CSS for the whole web, even if most of it never appear on the current page. (The rest appears mostly just once [header/footer/sidebars/pager etc.], or <10 times [titles on node-teasers for instance], so file-size-wise it's far from being effective, as compared to plain HTML.)

Otherwise, I agree with you that MS is not the right man to rule web manners, and that the situation should be encouraged to improve. But, gosh, this is not a noble conferrence about web's future: We're just trying to serve good-loking pages to our users right now!

litwol’s picture

Quit your bashing. if your site breaks under table-less design then dont use it!

on my site i successfuly and quite easily combine tables and tableless design!

my main 'frame' is laid out with tables, but content within the frame is formated using css.

so instead of pointing fingers at people for making the tableless theme, you should go and make your own, just like i did.

good luck

Sometimes something interesting appears on

JirkaRybka’s picture

This is exactly what I did on my site (tables plus CSS inside).

I'm sorry if I sounded as "pointing fingers", sometimes I find it difficult to express and defend my opinions, while struggling with English too. I'm not native English speaker.

But still, some people sound to me as promoting tableless design in a too enthusiastic way, this always upsets me. I may be mistaken as well, ofcourse...

litwol’s picture

my recomendation to you and anyone facing this problem is: ignore everyone and do whats needs to be done to get the job done.

Sometimes something interesting appears on

JirkaRybka’s picture

But still I feel like saying my opinions somewhere (here), to give a chance for newbies to hear it. Personally, I heard only how tableless design is the only way to go, when I started. Then wasted weeks of my precious time, struggling and failing on that, before I finally started over with tables.

By the way - my theme is here:

litwol’s picture

i see. well from personal experience i found out that the reason why i failed with tableless design is because i simply wasnt 100% knowledgeable about the innerworkings with CSS, i'll take a wild guess and say you are in the same boat with me. so i cut unnecessary hours of research i just went with tables for a small part of my design.

however i found out that with pure css i do gain much higher level of flexibility and much easier to implement it than with tables. ( i still had to use some css to overcome numerous tables limitations).

also lets face it, the different between tables and tableless design is that tables come with a set of tags that have predefined befavior that we all love so much, i tried css' table markups but IE doesnt handle them at all yet, i believe when IE implements the table css markups then table designs will get closer to extinction.

here's some info:

as much as we all love to continue using the tools we come to know so well from past experiences, we musnt close our eye to new technologies. css shows much promice without imposing numerous rules that tables do, i would promote tableless design just for that reason even if css isnt 'perfect' yet (what is?). yes css has some problems, yes they are causing us numerous issues, but instead of promoting how bad it is over table design we should look into how to fix it isntead of shout from the side lines how much it sucks.

morale of the story is:
1) fall back onto what you know and later take the time to learn new techonlogy to improve your project if you are under tight schedule or when things just dont work
2) dont blame the technology if it doesnt do something you want without first: 1) learning all possible ins and outs and hacks that somehow everyone else manages with and 2) contributing back to the community to help create that 'something' that you want
3) we are all comfortable in our shoes with the old technologies that we learned long ago and used for so long, but there will be times when we have to get out of the comfort zone and tackle the problem head on and spend numerous hours really stressing over it until we finaly solve it (or to shorten it up: things that worth something in life are never easy )

Sometimes something interesting appears on

JirkaRybka’s picture

The morale 2-2 (contribute back) brings us to another big question, often seen around: Who's developer, and who's user, and what are they supposed to do?

Developer makes the software, and even if not being paid for it (as often happens with open source), should consider users' needs and welcome feedback. He's not required to produce perfect solutions, but somehow expected to try.

User uses the software for any purpose he needs, and usually he doesn't have enough time / skills / motivation to create necessary patches himself. He just needs to deal with his own job, using the software merely as a tool. Running into a bug, the user is most likely to file bug-reposrts, complain, switch to another software available - very rarely will he stop his actual job, and go developing himself.

Now, developers often say "don't complain until you've provided the solution yourself". This is forcing the user to either:
- Become a developer (most users won't)
- Shut up and accept the open-source software to be buggy and somehow unsupported (poor job on open-source promotion!)
- Go away (and possibly buy Bill Gates' products instead)

There will be always a great number of "just users" around here (and it's good, without users there wouldn't be any point in developing at all), but treating them this way helps MS and the like more than open-source, I think.

As for this thread specifically - perhaps I'm a kind of amateur web-developer, but speaking of CSS, I'm just user, so I behave accordingly.

tonyf12d’s picture

Drupal is a CMS so the users would be webmasters. If it's someone employing someone to install drupal (such as a company), making a theme should count towards it as installing Drupal takes about 10 minutes.

JirkaRybka’s picture

Sorry, but I somehow didn't get your point.

I maintain a Drupal site, which is community-based (non-computer, it's naturists), so nobody employed me, but as of 4.7.x, which we started on, custom theme was a must (no Garland in there yet, other themes didn't look good). Installing Drupal core might be fast, but real site needs loads of contributed modules, which need much more time. That's a bit irrelevant here, though.

My point was, that I don't spend my time neither inventing new CSS rules, nor implementing them in some browser's source-code, nor patching that. I only just use the existing CSS in the process of theming, and if I spot a problem, I'm not going to join W3C experts' group immediately. I'm only just an user here.

Similar with Drupal: I choose and install contrib modules, do admin settings, create some contents to get the site up. If I come across bugs in code, I'm not going to spend months on debugging all that, some things I even don't understand. I'm just an user. (To be honest, I did a few patches, some of them already commited to Category project for instance, but only where I was able to, and really needed it for the very site I was working on.)

Developing software is a big job, I know it just well (I was hobby-coding for 15 years on 8-bit computers, developed my own operating system, numerous utilities, games...), but I don't choose to live this kind of life. Not anymore. And I believe most people wouldn't choose it.

I feel like to quit this thread, as it's gone from the original topic...

Shai’s picture

Dear JirkaRybka,

I just wanted to let you know I really appreciate your point-of-view and I'm very thankful for you for starting this thread. I'm about to launch on my first attempt to create a new Drupal Theme and was deciding between table/tableless and this thread has helped me much to think about the problem.

You were absolutely NOT whining or complaining in my opinion, you were just giving information and asking questions that I think is quite helpful to others and I wanted to thank you for that.


mcsolas’s picture

Tableless designs dont hold up on all sites in ' production ' environments.

Sometimes, its mandated by your job description to cater to them.

There is no absolutes here:
- divs dont always work
- tables can be inefficient
- Data tables and large scale media can break tableless designs.

Unfortunately, there is 1 sad but true fact to consider:

TD's expand properly when pushed in all browsers.

No other element, no matter how you style it, truly mimics the behavior of that tag.

Ive had to work with 30 column datagrids. No matter what and how I tried to clear that layout, those div tags wouldnt autoexpand and keep the layout from breaking. I hit up about 10 questions on experts exchange trying to sort it out. In the end, I threw that layout in 1 single table and got back to coding the server side code I needed to finish the app.

I implemented a template switcher:
- public pages render in a trendy div layout.
- admin CP is held inside a table.

Visually, both appear the same and now when the admin CP throws datagrids at my layout, it autoexpands properly.


tonyf12d’s picture

There is a CSS property display:inline-table, I'm not sure exactly what it's meant to do but it works in all browser I've tested it in (IE6 XPSP2, FF2.0.0.4, FF2.0.0.6, Opera 9.21-9.23) where it renders the div exactly as it would render a td.

Whether that counts as tableless is a different question though.

Td's do not always work either. Everything was new (and buggy) once.

JirkaRybka’s picture

Thanks for your reply, mcsolas. "TD's expand properly when pushed in all browsers" - it's true, and it brings another ideas to me, which I would like to say here:

It's not only just TD's expanding, it's the whole structure of the thing. Remember - if your TD expands, the table lines move and another TD's above/below are also expanded, so the page layout doesn't break! If - just for the sake of the argument - you somehow managed to expand the DIV - still other DIV's above/below won't expand and the site will be still broken.

Generally, in the software world, the best solutions (safe, efficient, bug-free, small filesize etc.) are the ones, where the logic of the software is a good analogy of the processed data structure. On the other side, emulating something on the basis of a completely different underlying structure is always difficult, painful, buggy, and very likely to crash any other day. Thinking of today's typical website from this angle of view, I'm quite unsure of the trendy tableless-dogma being a good thing.

The times, when websites were just fully-content-oriented HTML documents, are gone for good - today's typical page is actually a combination of more documents, pretty much like a frame-set. Look at this very page: Our discussion here is the main "document", but in the sidebar there are completely different things, which are not related, not written by us, not a part of this document. The sidebar (which is actually a kind of's toolbar) is logically another document. And there's even more on the websites seen around - ads, headers, footnotes...

CSS matches perfectly the logic of formatting inside the document, i.e. say "I want this picture to be somewhere to the right of this text-piece" (float: right), and don't bother about where exactly (relative to other elements - beside/under or the like) that picture will be in different browsers running on different screen- and window-sizes. Using small tables inside text, just to keep a picture together with its caption and decorative border around, allowing text to wrap around the whole, that's certainly a bad use of a table today, and I believe THIS is what the W3C recommendation say is deprecated ( This is a job for CSS.

As for the whole site (composed of more independent documents - regions), CSS logic doesn't fit. Tableless designs (which I consider rather nasty hacks, compared to clean and simple TD), just poorly and buggy emulate the presentation, which in its logic needs to be something like frames. In fact, I think that the basic idea of a HTML Frame-set ( was the step in right direction, but unfortunately it's not much usable (hardcoded dimensions, need for extra HTML files - search-engine unfriendly).

So, currently TABLE is the best we can do to divide page into regions containing relatively independent documents, ensuring positions of these regions relatively to each other (i.e. right sidebar on the right side, not falling to the bottom), as well as flexible dimensions of the whole to match any browser and any content, and avoid inner-formatting of the documents to interfere. The logic behind tables is the best fitting here (actually average site IS a table with header, footer, and three cells - isn't it?)

So why are we so keen to leave a good (and fully browsers-compatible!) solution, and switch to something that's not fitting? Because someone says that tableless is the future? We should consider facts, not shouts about future. Perhaps it all came from W3C recommendation (linked above), where it says: "Tables should not be used purely as a means to layout document content..." But we're NOT laying out document content - we're dividing the space between more documents, more different topics. This is not the job for CSS (unless heavily improved in future), this is like a well-fitting workaround for poorly behaving Frames.

Someone might say things about accessibility on non-visual media, or abstraction between contents and presentation (one of basic ideas behind CSS, as I understand it). In my opinion, ONE table for said-above purpose of site-regions-formatting is fully OK. The border between navigation-sidebar and real site-content, in my opinion, is a very important content-structure, not merely a presentation. I believe that these three TD's would help anyone using non-visual media to distinguish between content, site-navigation, ads etc. much better, than hundreds of DIV's already spamming the whole site. Taking only plain-text from the site, you don't want to have sidebars mixed-in - again I think that TD helps more than some float-definition hidden in CSS.

It's all about the concept of different site-regions being sort-of independent documents, which I believe is true.

Zahor’s picture

I'd agree with your argument 100%..if I didn't know CSS.

Tables are definetly not acessible - acessibilty goes way beyond just "distinguish between content, site-navigation, ads". I've used it to have a different layout based on screen size (but not expanding), formatting for printing and for mobile devices - all done without having to go through the numerous pages of content.

On one particular basic HTML site, client at the last minute wanted to change content dimentions around. (I just tried to imagine having done entire site in tables, then having to go to numerous pages to edit the width of a table and move the tables around but because the layout was controlled by a few ids in a css file, the change was done within minutes).

CSS works if you know how to use it.

People are always resistant to change - no matter what the arena. In the ever evolving world of web design, if you choose to be stuck with "the evil you know" go right ahead. For one, it leaves more jobs for the rest of us.

JirkaRybka’s picture

I was somehow speaking of Drupal sites and similar, where changing dimensions of a table (in page.tpl.php) is as simple as changing CSS. I think tables are not "the evil I know", tables are alternative to CSS, sometimes better and sometimes not.

If tables are not accessible, then we definitely need frames for this purpose, or something entirely new. CSS layout is the least accessible in my opinion, requiring to go through, in fact, non-structured text of the whole site to find the actual contents.

Zahor’s picture

If you are publishing a data grid, you obviously need to use a table. I've seen people who use css get carried away and forget that tables can still be used in "tableless designs" just not for the layout! When you have data (like a grid) you use a table!

I wouldn't know where to begin if I had to use a table for a page layout and have been using CSS successfully for quite some time now.
Those who complain, complain because they don't really know what they are doing. I can usually code a cross browser compliant page without even testing it, as I know how pages will behave and how to fix where necessary.

Zahor’s picture

IE is not being used by over 90% of users. Only 36.9% of users use IE6, Firefox is close with 34.5% and IE 7 is 20.1%. So that's the majority with browsers that work well!
I'm gonna use CSS and try my best for IE 6 workarounds. They need to get with the program as well as all you CSS haters!

JirkaRybka’s picture

I don't consider myself being a "CSS hater", I just use each thing where it fits best. For some purposes I like CSS, for others I like tables. I seek simple and clean solutions, no dirty hacks.

Can you please explain the simple, basic question, WHY should we avoid tables for site regions, even with very different / unrelated contents inside (and frames not being usable)?

Steel Rat’s picture

I'm with you, JirkaRybka.

CSS is for Styling, not for content division. I HATE divs with a passion, they're just that much more difficult to troubleshoot for layout problems. Yes i may be stuck in the past, wanting to use tables as much as possible, but the over-used saying works here: If it aint broke, don't fix it.

Steel Rat
Drupal Site:

Zahor’s picture

They are more difficult...if you don't know! Tables are too much trouble because if you want to edit you, you run the risk of messing up your content! Then in complicated sites where you have nested nested nested tables, it gets really really ugly and clunky. And I said it before and I'll say it again: there's no easy way to edit the same table in 15 different templates....unless you are using css.

I haven't heard much talk of it, but how do tables work with fluid sites?

JirkaRybka’s picture

Fluid - you mean variable width, accomodating to window-size?

This is one of major reasons why I gave up on CSS: Table truly accomodate, sensibly changing column-widths to match the contents (in the worst case, such as large picture in small browser-window, triggering horizontal scrollbar, on the site at large - not just on one element, but NEVER letting the site-layout to break.) CSS in the other hand gave me a lot of trouble, particularly with percentage-widths behaving strangely in IE 5 and 6, and no ability to deal with large fixed-size contents (big images). There are issues with tables too, particularly how to ensure minimum-width of a column, but still I found it more fitting and less workarounds-needing.

As for the editing-difficulty point - of course any template-editing must be done cautiously. But I see CSS as more risky, because the settings are "miles away" from the affected HTML, and in complicated situations (such as Drupal's CSS overriden by theme CSS) it's difficult to know, how many places will be affected by editing something. That's Drupal's issue though, not CSS itself.

One more idea - in W3C recommendation on CSS ( - chapter 1.4) it says: "you can make any element emulate almost any other. Relying on this power is not recommended, since it removes the level of structure that has a universal meaning (HTML elements). A structure based on CLASS is only useful within a restricted domain, where the meaning of a class has been mutually agreed upon."

I'm afraid, that reducing HTML structure to only just DIV element, and defining all the other structural stuff in CSS is exactly this "not recommended" use of CSS.

Zahor’s picture

As for the editing-difficulty point - of course any template-editing must be done cautiously. But I see CSS as more risky, because the settings are "miles away" from the affected HTML, and in complicated situations (such as Drupal's CSS overriden by theme CSS) it's difficult to know, how many places will be affected by editing something

That is totally untrue. You just use selectors (#wrapper #left-sidebar #node-105 .content {styles go here}- something like that) - so you can pinpoint exactly where you want to edit that particular style so you can say. It's beautiful! and I envy the guy who doesn't harness the power of css in these ways. Even if you do use tables for structure, you'd be foolish not to use CSS to style.

To each his own...I can get a fluid site complete with min-width that works in all browsers up and running in a few minutes. The first time it took me over an hour - but again, once you know these things...

tonyf12d’s picture

The default theme for new drupal installations is fluid without tables.

JirkaRybka’s picture

Okay, using highly-specific selectors like #this #that to apply CSS only to one place reduces the editing difficulty to just searching two files for matching selectors instead of seeing the thing right there in HTML code, but this (styling elements one at a time) is quite against the concept of CSS, isn't it? It leads to very large files and doesn't make things any better, only just moving the information from one file to another. CSS should address elements by classes, by some kind of groups, otherwise it's senseless - or am I missing something here? Also using selectors with ID's often makes it impossible to override later (particularly by inline-styles, if needed, which is a possibility I like to leave open).

But I was speaking of Drupal, where I mostly have to stick with already-generated class-names (unless I want to override a large number of theming functions only just to change class-names or turn these into ID's), and override existing Drupal's CSS, making the whole a bit more difficult to maintain, than writing from scratch. Even in your example, styling #wrapper .content .item-list li would affect a dozen of very different places, no matter how many id-selectors you put above it. CSS is not exactly the heaven of simple editing, although the maintainer's experience certainly counts, as you're probably trying to say here. But this is not about tables vs. CSS, this is a different issue.

BTW - I already use tables for structure (where it really IS a structure, i.e. sidebar vs. content vs. footer), and CSS for style (i.e. floating picture, font size and colored border). It doesn't help me with neither file-sizes nor editing-ease (rather the opposite), but still I like to keep things in the right place.

tonyf12d’s picture

While 90% is a high estimate (and all browser percentages are just estimates) Between IE5,6 and 7They have 75% share, FF has 20%, Opera has .8% and the rest is usually older browsers (mozilla and IE4).

It's still a large majority.

Zahor’s picture

IE 6 isn't in the same boat as IE 7. IE 7 doesn't have as many bugs and you can most times code to css standards without running into problems with IE 7.

itzme’s picture

I too prefer css based formating, we should learn to stick on to the basics first instead of venturing into something too technical.

rp1428’s picture

It's clearly a preference. I've wrestled with this this week. On the basis of usual software development measures; getting it done fast; it works; it's cost is contained and its is maintainable, I have to say that a combination of tables/css for layout and css for styling is my decision. IMHO css is not suitable for page layout alone for some of the reasons below. I also appreciate that the comments below are an opinion - if you have an opinion then share why you think I am wrong - I would love to avoid tables but I just don't think that it's productive and my approach is to get the job done, working and know that I can go back to it and change it in 6 months. Also with Drupal that my client can remove and add blocks without destroying the web site style.

1. Effort of layout is much greater. Getting floats and negative margins and padding all correct is an interesting challenge but not terribly productive. A table width specified widths and spacer gif's is much faster. If you have a complex layout, every new div you add has the potential to affect what is already done.
2. Effect of change on css based layout is much more likely to affect layout. Bascially a change to one element could affect much of what is on the page making maintenance harder.
3. Css based layouts are much more like to show differences and have interoperability problems between browsers.
4. The nature of Drupal having styles in so many stylesheets makes css maintenance harder
5. The nature of Drupal having blocks that may or may not appear on the page cause the layout to be harder to manager. If one of my floated blocks does not appear because there is no content at that time, I don't want css to decide how to re-style my page.
6. There appears to me to be a problem with css layouts and Drupal. If I add a block it gets an arbitrary name and hence div id name. But this arbritrary name is what I need to use in my stylesheet and I am uncomfortable that I am not able to associate these two items in a more specific way. I may be wrong about this and there is another way to do this.
7. Because of cascading and because of inheritence, you end up adding stuff (often with !important) at the end of your stylesheet which then grows.. Of course later you will go back and fix it :)

I spent three days tying to get what I though was a fairly simple layout working based upon Garland with multiple column floats in the content, header and right side bar areas. At midnight last night I converted it to a table layout and had the layout working correctly in under an hour. I am much more confident that the effect of change on what I have will be predictable and that maintenance will be easier. Plus, resizing in IE6, IE7, Mozilla, Firefox and Opera works the way I (and not CSS) want it to.

gopher’s picture

Other people have said enough, but I just find it very telling that the original poster's website design looks like the work of an amateur to put it nicely, and yet he's preaching about web design as if he were a professional. It's also ironic that he says as a mere "user" and not an expert of CSS he shouldn't have to deal with problems like CSS browser support, yet goes on to denounce all the real experts for using CSS for layouts. Which is it? Are you a user who doesn't know about CSS? Or are you an expert giving an expert opinion on who should use CSS for what?

I can understand that people who don't really care about web design might want to use a table based layout to just get the job done quickly without dealing with the IE6 learning curve. So for that, more power to you. But to come and bash people who use CSS for layouts? It only shows your ignorance. There's a reason why the vast majority of the largest sites on the internet use CSS for layout. And if we never though about the future and how to improve technology we'd still be using text only browsers like Lynx. Or better yet we'd all be cavemen walking around naked... sound familiar?

Edit: There was a time not that long ago when people had to design for NN4. Now nobody does. When IE6 is where NN4 is, the majority of CSS-for-layout headaches are gone. That day is not that far away, IE6 is now under 40%, and it was at 95% not that long ago.

JirkaRybka’s picture

Just to explain...

The layout at was done a year ago, I learned a lot since (today, I'll not go with tables so deep in the structure), but still I'm not going to redo that theme in its basic features. (This is not about color shades and background pictures, which are matter of webmaster and audience's taste, right?) I see that CSS is good for styling, and NOT for emulating frames (in other words dividing contents into independent regions). I stand behind this major point, and I think that in this context it's a bit irrelevant whether I'm a professional or not, whether I know CSS hacks or not. I see on other pages ( including) plenty of examples, that even the professionals, even with hacks, are unable to get the thing working properly. This thread is not about not/knowing detailed hacks, it was supposed to be about the basic concept, exactly the thinking about future you mentioned. Thinking about future means constant seeking of best solutions - not just blind promoting of the ones already agreed upon, even if serious flaws surfaced later. I'm dealing with various sorts of software on various platforms for about 20 years now, I see analogies, I see visions... I think I feel what's clean and what's not (which might be wrong easily), and so I wanted to discuss these ideas on rational, independent basis. Perhaps my relatively small experience with webdesign qualifies me as "fresh angle of view", as my mind is not slave of "what's commonly said". Although I studied the tableless themes quite a lot in structure, before dropping that concept.

My points, summarized, are:

1. Top-level regions of average website (such as sidebars vs. main content) are in fact independent documents, and it's a mistake to merge them into one soup, to be only separated by (omittable) styling. It's an important content-structure, and so needs to be clearly specified in HTML just like the text itself.

2. There's need for a clean, simple mechanism of dividing a page into regions, where the underlying logic matches the wanted structure, so that it may not break due to the very principle (i.e. sidebar tied to the right beside other regions, acomodating contents without losing width-sync with above/below regions, and not free floating anywhere browser wants) - as oposed to current CSS formatting, which stands on completely different logic, causing misbehavior in cases like a narrow screen or user submitting a big picture.

3. Since Frameset is not behaving well, table is currently the best choice to accomplish a page divided into regions (like said above); if table is seen as incorrect solution for content division (which I don't see why), then we need a completely new HTML structure for this purpose.

4. CSS is for styling, i.e. controlling the presentation of a document. Using it for building the very structure of that document (or even the borders between more documents), or hijacking HTML tags to behave like other ones (using only just <div> for everything) is clearly a misuse, as even the W3C recommendation itself says for some cases.

I'm starting to repeat myself :-/ If there's someone out there able to give sensible reasons why I'm wrong (other than just going against common opinions, or having a year-old site not well tuned), then go on. Otherwise I consider this thread finished.

rajsanand’s picture

But I would like to tell you that I was where you are now, I think I was worse than you, till very late I have not used css. I always used a combination of tables(not for data but for centering etc) and css-divs.
It only took me 3 weeks to learn or rather open up my mind to css.
Everything you speak about, like width not being fluid as compared to tables is wrong.
The width and heights are fluid in css divs. You just need to know how to set widths to 100%, wrap them in a "wrapper" div and if you add more content in 1 div then the div above and below or left of right will change with it.
You just need to know how. Once you learn how to do it, it hits you like zen and then you too will go around singing praises of table less designs, just like the very people you(and me) used to hate.