What it comes down to for me is, CSS only takes you so far when 40% of your users are still using a browser that was written when CSS was still just starting to take hold (that is, IE 6). I don’t think most of the table-lovers of the world would have much of a problem switching to full CSS for most use-cases if all the browsers they had to program for actually implemented CSS well. The fact is, for many of us, one of the largest target audiences does not use such a browser. I try, I really try, but when I spend 3 hours on a layout, get it working in 20 minutes for all but one browser and have that last browser just not cooperate and not cooperate, all the while knowing that with two little table tags I can get that browser to do exactly what I want (and all the other browsers would work with that too) – yeah. I’m going to just use a table.

Here’s an example. You’ve got a row of thumbnails (variable width). Each thumbnail can have completely different dimensions (but must fit in, say, a 60×60 square). On the upper-right corner of that thumbnail, you want a circular delete button where only 1/4 of the button overlaps the thumbnail. That delete button only appears when you hover over the thumbnail, and when you hover over the button, it also has a separate hover and active state. The thumbnails must be dynamically resizable with a slider, and even after resizing that delete button’s gotta be in the same place. The thumbnails all must be vertically centered with each other (remember, they have different dimensions), and there should be a vertical line between each thumbnail which does not touch the top, or bottom of the container. (I know, sounds really complex – but I’ve hit this exact use case over, and over, and over again – my designers love this stuff). Now, tell me, how do you do that in IE 6 without tables?

This is when the CSS purists usually say to me, “well, you should just make a simpler layout”. Right.

Now, if you think that’s bad, imagine what the Ext people have to deal with to work some of their magic with grids, and trees, and toolbars. And keep it IE6 compatible. And you’re going to harp on them, because they use tables sometimes? You should be grateful it works at all. When you get proper floats and margins, all “display” options (including inline-block), vertical-align, and max-width/min-width working in every major browser, then we can start preaching about the misuse of tables. Until that day (and I don’t know about you, but I’m definitely looking forward to 7/13), let’s just be grateful we can accomplish these layouts in the first place.

Well, I think that the TableLayout layout manager is not widely used for general layout of Components in Containers.

More likely since Ext 3 came out would be the “box” layouts, VBoxLayout and HBoxLayout which offer flexible sizing and laying out of child Components based on a scheme similar to that outlined here: http://ajaxian.com/archives/css-3-flexible-box-model

There’s a difference between a table for tabular data and tables within tables within tables and so on, which is what I remember seeing. I don’t know if recent versions have moved away from that, but that’s what I remember seeing. I think even the most ardent tables supporter would say that’s probably not appropriate, when looked at from the point of view of CSS vs. tables for layout.

Which is the most appropriate thing in the world. It’s a table.

Given some of the arguments against using tables for layout, things like bandwidth and CPU utilization and “semantic” correctness for example, it *does* I think matter, to some people at least, what Ext JS does underneath the covers. From what I remember the last time I looked, Ext JS does in fact use tables quite a bit (I remember the generated markup for the Grid in particular being very table-y).

I agree that when you’re developing an application with Ext this generally isn’t your concern… I know it isn’t mine, and I do *a lot* of work with Ext… but for those that are vehemently anti-tables for layout, I would expect they’d raise the same sorts of objections and apply them to what Ext JS generates.

Then again, I could argue that using Ext, or any good toolkit like it, is another reason the CSS vs. tables argument is less important… the whole goal of abstractions, of which Ext JS certainly is one, is to hide details to make building more complex things easier (and obviously to stop reinventing the wheel every time). At what point do you stop worrying entirely about the details of a given lower level of an abstraction? Is one level removed OK, or do you need five before you don’t care? Or is there NEVER a time where you ignore the details? (at which point you’ve got to wonder what the point of an abstraction is!)

I personally don’t worry about what Ext JS produces code-wide (unless I have specific reason to), but at the same time I can see where someone else would be concerned with that… I wonder if that means that the “CSS-only” crew is inherently anti-Ext JS and indeed anti-any high-level GUI toolkit like it that isn’t 100% CSS-based? I’d be willing to wager that few toolkits, if any, actually are as pure as the CSS-only folks say markup should be… Logically it seems like they’d HAVE to be against these toolkits, no?

Err, yes. That’s why there is the possibility to use layout: ‘table’

It’s if you are wanting to present data in a tabular manner.

If not, use another layout!

(sheesh!)

To me, it’s akin to saying all planes should always be jet planes because jet planes are clearly better than prop-driven planes. It’s hard to dispute that by most criteria a jet plane wins, but there’s plenty of people who would advocate the other way, and for quite valid reasons.

I have no problem saying we should favor CSS, and that we should only use tables by exception, I think that’s the right approach frankly. To say you should ONLY EVER use CSS though, in my mind, is far too rigid a mindset… as a client, I’d actually be more inclined to turn away someone who appears to have an inflexible mind over someone I might disagree with about something.

* “mixes presentational data in with your content.”

Ok, fine, I don’t disagree, and the forward-thinking “semantic web” crowd have a valid point here. But…

* “This makes the file sizes of your pages unnecessarily large, as users must download this presentational data for each page they visit.”

Err, if I DON’T download presentational data for each page I visit, what in the BLUE HELL am I looking at on my screen?!? CSS is wonderful, but CSS applied to no content looks like…umm… what’s the phrase… A BLANK PAGE?!? I don’t know, seems like I have to download presentational data either way. I suppose someone will come along and say I’m defining “presentational data” wrong, so I’m all ears.

* “Bandwidth ain’t free.”

Yes, granted. The whole “size and speed of rendering” argument is definitely valid. However, have you ever really compared a complex CSS-based layout to a similarly-complex table-based layout? I have. Guess what? The difference isn’t typically that big a deal in terms of bandwidth utilization. I’ve even in one or two cases found the CSS approach to result in MORE bits going across the wire. I’m sure the CSS wasn’t as perfectly-optimized as possible, but then, neither was the table layout!

Processing speed is the other typical argument, and while I accept that *generally* CSS-based layouts are less processor-intensive, I’ve seen some cases were the exact opposite is true. Remember, tables have been around before CSS (at least, CSS with any sort of complexity)… browsers are pretty well optimized for tables at this point and are I think only now being optimized really well for CSS, in the past 2-3 years maybe.

* “This makes redesigns of existing sites and content extremely labor intensive (and expensive).”

Again, while CSS is very cool, I’ve in my entire life met so few people that find designing a CSS-based layout to be easier and faster than table-based layouts as to not be statistically important. I agree, if you’re an absolute CSS God it’s probably no big deal to knock out virtually any layout, and it’s certainly no more difficult for you than tables… but there’s not many of those folks around frankly. Most of us can manage what we need to with CSS, but it’s often times a bit of a struggle. You’ll never convince me that designing with tables isn’t easier and faster, and therefore cheaper and less labor-intensive, than a CSS-based layout, unless the layout is so simple that they’re about the same anyway. Maybe 10 years from now I’ll say something different, but not now.

* “It also makes it extremely hard (and expensive) to maintain visual consistency throughout a site.”

If this is taken to mean that it’s easier with a CSS-based layout to change the layout across an entire site, then yes, absolutely, no argument. There’s certainly server-side tricks you could play to make tales about as easy, but I’m an RIA man myself, so even *I* don’t like that answer :)

* “Table-based pages are also much less accessible to users with disabilities and viewers using cell phones and PDAs to access the Web.”

I want to see evidence of this. I’ve personally seen FAR better support of tables than CSS across constrained devices such as cell phone, and I dare say that screen readers can deal with tables just fine from what I’ve seen.

I’m not necessarily taking sides here… I think there’s some fair points on both sides… but, it does seem that the CSS purists are the louder, more obnoxious side of the debate, and that turns me off. At the end of the day, let’s put the religion aside and just get our work done, how’s that?? :)

1) I don’t know if the actual “table” tag is even used in an ExtJS table layout (completely different things).

2) Microsoft Excel was not originally made to layout designs — the “table” tag WAS originally made to provide a page layout. Your analogy doesn’t fit.

…but this would not be a quick sell for me to use ExtJS.